We announced the release of VE 6.1 today (Press release here). It is primarily a point release that provides several usability enhancements and takes advantage of the latest features in NetBeans 6.1 IDE.
In addition, VE 6.1 is also being featured in an on-demand, joint webinar hosted by NetBeans as part of the NetBeans 10th birthday (Congratulations to NetBeans on it's 10th Birthday !). In this webinar, I demonstrate the capabilities of VE 6.1, built on NetBeans 6.1, and show you how VE simplifies the development of web based applications and web services using Model Driven Development approach.
Intelliun's webinar is part of the NetBeans Decathlon - ten interactive tasks for the NetBeans community to show and share what NetBeans means to them. You can watch the webinar by taking part in the decathlon or if you would like to just watch the webinar, you can find it here.
You will also be able to download an evaluation copy of VE 6.1 platform later on this week from the Intelliun web site.
Monday, October 20, 2008
Tuesday, September 30, 2008
OMG September Technical Meeting
Intelliun is ramping up its participation in the Object Management Group, and as part of that effort I attended the OMG September Technical Meeting in Orlando, Florida. The conference hotel was actually inside the Disney World property, but it was on the opposite side from the Magic Kingdom, and a busy schedule didn't allow time to go frolic with the mouse.
Even without the full Disney experience, it was pretty fun. Aside from my presentation (a bit more on that below) there is exciting news on the Executable UML front, with the Semantics of a Foundational Subset for Executable UML Models being recommended for adoption and an RFP for a Concrete Syntax for a UML Action Language being recommened for issuance. The documents are slow-going, but I especially liked the appendix with a mapping of the formal semantics onto Java.
My presentation at the MDA Users SIG was How MDD Changes Software Development Processes. In short: you should be able to use your existing process (especially if it's an iterative approach), but there are some differences in scheduling, resource allocation and testing that you should probably take into account. I'll post the slides soon.
Friday, May 16, 2008
JavaOne 2008 : Gee whiz mister, that's kinda neat.
I've been using VE for long enough that the "gee whiz" feeling has worn off, but seeing people react to the demos I did at JavaOne brought it all back.
There were a couple of features people responded to especially strongly. The simplicity of getting a model-driven application up and running was one of the biggies. I suspect people have been conditioned to think "model driven" means "long term benefits at the cost of a nasty short term learning curve". It was fun showing how you can going in just a couple of minutes.
Web developers liked the continuation[1]-based workflows that let you specify a complex linked set of interactions without having to do your own state management or routing, and everybody got a kick out of the "execute" button that lets you run the model even if you've just specified a couple of incomplete classes.
OK, evidently when I'm enthusiastic I write stuff that reads like a sales brochure, but if you can get past that definitely check out the continuations-based stuff. It means your web application code looks like ordinary desktop application code (do something, get some input, based on input decide to get more input, etc). It doesn't hit you how much easier that approach is until you have to go back to coding the usual way. It's probably worth a whole blog post just on that.
[1] http://en.wikipedia.org/wiki/Continuation#Continuations_in_Web_development
There were a couple of features people responded to especially strongly. The simplicity of getting a model-driven application up and running was one of the biggies. I suspect people have been conditioned to think "model driven" means "long term benefits at the cost of a nasty short term learning curve". It was fun showing how you can going in just a couple of minutes.
Web developers liked the continuation[1]-based workflows that let you specify a complex linked set of interactions without having to do your own state management or routing, and everybody got a kick out of the "execute" button that lets you run the model even if you've just specified a couple of incomplete classes.
OK, evidently when I'm enthusiastic I write stuff that reads like a sales brochure, but if you can get past that definitely check out the continuations-based stuff. It means your web application code looks like ordinary desktop application code (do something, get some input, based on input decide to get more input, etc). It doesn't hit you how much easier that approach is until you have to go back to coding the usual way. It's probably worth a whole blog post just on that.
[1] http://en.wikipedia.org/wiki/Continuation#Continuations_in_Web_development
Wednesday, May 14, 2008
Intelliun @ JavaOne 2008 (Continued)....
JavaOne 2008 is over and thanks to all the folks that visited us at our booth, it’s been a great success !
At the show, we’ve announced the release of The Virtual Enterprise 6.0 Beta (link to the press release). VE 6.0 is the latest generation of The Virtual Enterprise product suite, packed with a host of new features and enhancement(Press release). Response to our product features and demo at the booth has been terrific and it was great to see the interest and enthusiasm expressed by the developer community.
We had a lot of traffic at the booth and hopefully all of you had an opportunity to watch the demo and experience the simplicity and productivity offered by VE 6.0 in building enterprise class business applications and web services. In case any of you didn’t get a chance to see the demo in person, here is the link to the demo from our web site. The new beta release will be publicly available for download shortly – so keep an eye out for updates regarding that in the next few days.
Intelliun is now an official strategic partner of NetBeans ! We are quite excited to be a NetBeans partner and look forward to a mutually rewarding partnership between Intelliun and NetBeans. VE/Designer 6.0 is built on top of NetBeans 6.1 IDE and leverages many great features and extensibility offered by the NetBeans platform. If you were at CommunityOne on May 5, you might have seen our CEO, Iyad Jabri, giving a lightning talk on Service Oriented development using MDD during one of the lightening talk sessions.
In addition, Intelliun is now a member of OMG and I fully expect Intelliun to be involved and contribute to the model driven development initiatives undertaken by OMG moving forward.
Sunday, May 4, 2008
Intelliun @ JaveOne 2008
The Intelliun team will be in Booth # 640 on the pavilion floor at the JavaOne 2008 conference, scheduled to to start on Tuesday (May 6, 2008). Please do stop by the booth and visit us if you are going to be at the conference this year. In addition to watching a demo on how to build business applications and web services in a matter of minutes using Model Driven Development, you might win some cool give aways !
Also, don't miss the lightning talk session on building service oriented business applications using model driven development by an Intelliun team member during CommunityOne sessions on Monday, May 5, 2008.
Also, don't miss the lightning talk session on building service oriented business applications using model driven development by an Intelliun team member during CommunityOne sessions on Monday, May 5, 2008.
Wednesday, April 2, 2008
What is MDD? (Part 3)
Executable Models is one of the approaches for MDD. This post concentrates specifically on UML-based models. The idea is to use the minimum but necessary set of models to capture the domain logic, and make it immediately executable without further coding, compilation, and deployment.
As a quick background to set the context, developing a piece of software (whether done formally or informally) starts with capturing the functional requirements, analyzing it to better understand the problem and identify wholes and contradictions, then developing the abstract design to prescribe a solution to the problem independent of the underlying technologies and target architecture. The non-functional requirements are used for developing the target architecture including specifying the involved technologies, approach, patterns, etc. The marriage between abstract design and architecture results in the detailed design that can be coded, compiled and executed.
Accordingly, if you specify the target architecture upfront, then you’re able to automate the process of going from the abstract design to details design, coding and compilation. And, with a little of dynamic loading techniques, you can also eliminate deployment and blur the line between development and runtime.
So this takes care of the executable part. Now for the minimum but necessary set of models, a close study of any object-oriented programming language would reveal that it offers three constructs for development: static constructs like a class definition, dynamic constructs like the implementation of an operation with various flow-of-control statements (e.g. if-then-else, looping, etc.), and an expression syntax. Accordingly, if we identify the equivalent models in UML then we’re equally able to develop any application.
For the static construct, the UML Class Diagram is a great substitute for the text-based class definition code. You’re able to define one or more classes with their attributes, relationships to other classes, and operations (the declaration part only). For example, with a single line from one class to another, you’re able to specify the class member and type (including a typed-collection if it’s one to many), ownership (if any), the directionality (i.e. uni- vs. bi-directional), and visibility. And with a little bit of rule annotation, and you’re able to have a semantically complete model, that is ready to execute. A simple diagram that takes minutes to draw and comprehend can easily replace pages of code.
As far as the dynamic model to provide the implementation of operations, the UML Activity Diagram has all of the elements necessary to capture the flow-of-control similar to code statements. The Activity element is used to capture simple expressions, and you’re ready to execute the model. The operation declaration provides the signature including in/out parameters, and the Activity Diagram captures activities to traverse and manipulate the state of instances of the object model including by calling operations on other objects. Granted that the Activity Diagram might get crowded, but if the developer is experienced, your operation implementations should have no more than two to six activities (common metrics for quality of OO code).
Finally, expression syntax is very important. UML includes the Object Constraint Language (OCL), yet doesn’t prescribe a specific syntax. Regardless, pick your favorite expression syntax, say Java for example, add higher level operators that assist in the navigation and traversal of your object model, and you’re in compliance with OCL.
Now if you strip out all interface (specifically user interface) and persistence logic and focus on the domain logic, your models using the above can be readily executable. This changes the development paradigm altogether, where you’re able to use very small increments to model different parts (use cases) of the application and execute it for a quick validation. If you don’t like the results, quickly change the model and hit execute! This has a huge productivity gain that go far beyond even Smalltalk with its ability to immediately execute the logic by highlighting it and clicking Run It.
Going back to the interface logic, since it’s an important part of any application, the static model has the semantics necessary to render an instance of any class to a target client device (e.g. a web browser). If you limit the communication of an external entity (an actor) on the system to the execution of operations and the interchange of objects, you’re able to directly interact with instances of your model and validate the behavior of the system without any further coding. As far as personalizing the look and feel, there are many WYSIWYG approaches that can be used to control the rendering of an object instance to a specific look with a fraction of the time compared to normal development since you always start with the model (hence, no tedious wiring code).
As far as persistence, the static model (Class Diagram) also has all the necessary semantics to drive the generation of the data model (that can be automatically deployed to a live database instance), along with the SQL statements and the Object-Relational Mapping to transform the data back and forth. OR-Mapping is mainstream today even for hand coded applications.
This is getting to be a long post, so Part 4 will discuss the advantages and disadvantages of Executable Models.
As a quick background to set the context, developing a piece of software (whether done formally or informally) starts with capturing the functional requirements, analyzing it to better understand the problem and identify wholes and contradictions, then developing the abstract design to prescribe a solution to the problem independent of the underlying technologies and target architecture. The non-functional requirements are used for developing the target architecture including specifying the involved technologies, approach, patterns, etc. The marriage between abstract design and architecture results in the detailed design that can be coded, compiled and executed.
Accordingly, if you specify the target architecture upfront, then you’re able to automate the process of going from the abstract design to details design, coding and compilation. And, with a little of dynamic loading techniques, you can also eliminate deployment and blur the line between development and runtime.
So this takes care of the executable part. Now for the minimum but necessary set of models, a close study of any object-oriented programming language would reveal that it offers three constructs for development: static constructs like a class definition, dynamic constructs like the implementation of an operation with various flow-of-control statements (e.g. if-then-else, looping, etc.), and an expression syntax. Accordingly, if we identify the equivalent models in UML then we’re equally able to develop any application.
For the static construct, the UML Class Diagram is a great substitute for the text-based class definition code. You’re able to define one or more classes with their attributes, relationships to other classes, and operations (the declaration part only). For example, with a single line from one class to another, you’re able to specify the class member and type (including a typed-collection if it’s one to many), ownership (if any), the directionality (i.e. uni- vs. bi-directional), and visibility. And with a little bit of rule annotation, and you’re able to have a semantically complete model, that is ready to execute. A simple diagram that takes minutes to draw and comprehend can easily replace pages of code.
As far as the dynamic model to provide the implementation of operations, the UML Activity Diagram has all of the elements necessary to capture the flow-of-control similar to code statements. The Activity element is used to capture simple expressions, and you’re ready to execute the model. The operation declaration provides the signature including in/out parameters, and the Activity Diagram captures activities to traverse and manipulate the state of instances of the object model including by calling operations on other objects. Granted that the Activity Diagram might get crowded, but if the developer is experienced, your operation implementations should have no more than two to six activities (common metrics for quality of OO code).
Finally, expression syntax is very important. UML includes the Object Constraint Language (OCL), yet doesn’t prescribe a specific syntax. Regardless, pick your favorite expression syntax, say Java for example, add higher level operators that assist in the navigation and traversal of your object model, and you’re in compliance with OCL.
Now if you strip out all interface (specifically user interface) and persistence logic and focus on the domain logic, your models using the above can be readily executable. This changes the development paradigm altogether, where you’re able to use very small increments to model different parts (use cases) of the application and execute it for a quick validation. If you don’t like the results, quickly change the model and hit execute! This has a huge productivity gain that go far beyond even Smalltalk with its ability to immediately execute the logic by highlighting it and clicking Run It.
Going back to the interface logic, since it’s an important part of any application, the static model has the semantics necessary to render an instance of any class to a target client device (e.g. a web browser). If you limit the communication of an external entity (an actor) on the system to the execution of operations and the interchange of objects, you’re able to directly interact with instances of your model and validate the behavior of the system without any further coding. As far as personalizing the look and feel, there are many WYSIWYG approaches that can be used to control the rendering of an object instance to a specific look with a fraction of the time compared to normal development since you always start with the model (hence, no tedious wiring code).
As far as persistence, the static model (Class Diagram) also has all the necessary semantics to drive the generation of the data model (that can be automatically deployed to a live database instance), along with the SQL statements and the Object-Relational Mapping to transform the data back and forth. OR-Mapping is mainstream today even for hand coded applications.
This is getting to be a long post, so Part 4 will discuss the advantages and disadvantages of Executable Models.
Tuesday, March 18, 2008
Why MDD Works (Part 2)?
I know it’s been a little while since Part 1, but I didn’t foresee the “writers strike”...just kidding. It has been incredibly busy and exciting here at Intelliun, and time just flew by. Hopefully I will be able to block weekly time to add to this blog on a moving forward basis.
Picking up from where we left off, but before we get into the specifics of MDD, we need to take a closer look at programming, and analyze the types of code we usually write to develop a typical piece of software. If you strip out all of the standards, jargons and layers of complexity, you will find that code in any software falls into three categories: logic, interface and language/libraries.
Let me explain. Logic is “what” you wanted the software to do in the first place, regardless of technology or the “how”. This is usually where you have the value add (behind the software) and the innovation. However, it would make for useless software if it cannot interface with any external entities.
Interface code takes care of that problem. For example, if you want a human to interact with the logic, you have to build a user interface. If you need the logic to use another piece of software, you will have to build an interface, and so on.
Language and libraries are necessary to make your development easier. Instead of building the logic from scratch, you can use a set of libraries that save you time. Also, programming language specific syntax can save you a lot of work compared to programming in machine code. One statement can replace a page worth of machine code, and the higher level of programming language (the higher level of programming abstraction), the higher the productivity.
Here is a quick example to illustrate the above. To write a program in Java that would calculate the simple logic of adding two numbers, say 2 + 2, you would have to write:
public class TwoPlusTwo
{
public static void main( String args[] )
{
System.out.println( 2 + 2 );
}
}
Where the gray code is your language/library code, the blue code is the user interface code, and the red code is the original desired logic.
This should seem very obvious, but we don’t often think about it this way. It’s really important though so we can understand where we’re spending our programming time, and what we can change to make us more productive. Here are few opportunities for that:
Picking up from where we left off, but before we get into the specifics of MDD, we need to take a closer look at programming, and analyze the types of code we usually write to develop a typical piece of software. If you strip out all of the standards, jargons and layers of complexity, you will find that code in any software falls into three categories: logic, interface and language/libraries.
Let me explain. Logic is “what” you wanted the software to do in the first place, regardless of technology or the “how”. This is usually where you have the value add (behind the software) and the innovation. However, it would make for useless software if it cannot interface with any external entities.
Interface code takes care of that problem. For example, if you want a human to interact with the logic, you have to build a user interface. If you need the logic to use another piece of software, you will have to build an interface, and so on.
Language and libraries are necessary to make your development easier. Instead of building the logic from scratch, you can use a set of libraries that save you time. Also, programming language specific syntax can save you a lot of work compared to programming in machine code. One statement can replace a page worth of machine code, and the higher level of programming language (the higher level of programming abstraction), the higher the productivity.
Here is a quick example to illustrate the above. To write a program in Java that would calculate the simple logic of adding two numbers, say 2 + 2, you would have to write:
public class TwoPlusTwo
{
public static void main( String args[] )
{
System.out.println( 2 + 2 );
}
}
Where the gray code is your language/library code, the blue code is the user interface code, and the red code is the original desired logic.
This should seem very obvious, but we don’t often think about it this way. It’s really important though so we can understand where we’re spending our programming time, and what we can change to make us more productive. Here are few opportunities for that:
- Raise the level of abstraction for the programming language focusing more on the what and not the how (declarative programming)
- Provide richer libraries and programming syntax
- Eliminate the need for interface code, maybe for 80% of the cases
Model-Driven Development capitalizes on these opportunities, keeping the focus on the logic itself. The different flavors of MDD, however, follow different approaches of getting there at varying degrees of success. Part 3 will examine Executable Models in more details and how it capitalizes on these opportunities.
Subscribe to:
Posts (Atom)
