Today is the last day to fill out the survey for the Netbeans UML module.  So, I thought I would share some early results of the survey.  As of Sunday there have been 67 responses. if you have not already taken the survey, please take some time to give us your opinion.

The current results are as followings:

Stability: Excellent 34%, Somewhat 60%, Not Stable 6%
How Often Used: Often 42%, Somewhat 45%, Never 13%
Usability: Excellent 36%, Somewhat 54%, Not Usable 10%
Performance: Excellent 42%, Somewhat 54%, Not Adequate 4%
Documentation: Excellent 46%, Somewhat 52%, Not Adequate 1%

The interesting thing to note, is that almost everyone that said the tool is not usable said it was because it does not support generics.  I would like to hear more information about how UML does not support generics.  The reverse engineering and code generation does have generic support, but perhaps there are areas that are not covered so well.  I know of one important issue that was fixed in the last couple of days.  I think that this issues will make a big difference.  Please let me know what you think.

Types of Users
Design/Architect: 84%
Code Generation: 66%
Reverse Engineering: 75%

Diagrams Used
Activity: 34%
Class: 93%
Collaboration: 19%
Component: 30%
Deployment: 19%
Sequence: 58%
State: 33%
Use Case: 64%

Modeling Activities
Report Generation: 40%
Reverse Engineering: 66%
Code Generation: 69%
Design Patterns: 40%
Requirements Gathering:  36%

Generics was a new feature in Java 5.  This is not new, because Java 5 has been out for a long time now.  Now that NetBeans has UML support, we are getting a lot of questions about UML support of Generics.  I will make an attempt to demonstrate how UML can represent generics.

In UML every classifier can have template parameters.  Classifiers are things like Class, Interfaces, and even Use Cases.  To use a template you have to create an instance of the template.  The instance of a template is a new type.  Creating an instance of a template is similar to extending a class.  This is not to far fetched, because when templates was first added to C++, many C++ compiler would actually create a new class declaration for every new template instantiation.  Then compile the new template decloration.  So, ArrayList < String > is a completely different type than ArrayList < Integer >, and vise versa.  You can not assign a ArrayList < Integer > a variable that is declared to be of a ArrayList < String >.  UML has the same concepts.  UML actually has two different mechanism to represent generic instances. 

The first is called an anonymous classifier (In the NetBeans UML module, we use the term Derivation Classifier).  The anonymous classifier is used to define an instance of a template.  The anonymous class uses syntax to declare the template name, and the arguments being passed into the template.  The NetBeans UML currently does not use the UML notation, but instead uses a more Java like notation.

The second approach is to use a derivation edge.  You can draw a derivation edge between  a classifier and a template.  A derivation edge has bindings that are used to specify the template arguments.  The anonymous classifier is simply a shortcut, for the derivation classifier approach.  A problem with the derivation edge approach is that you there is no way to determine that a derivation is for generalizing from a class, or implementing an interface.  Code generation can try to determine if a derivation is for implementation or generalization, if Classes and interfaces are used.  However, if you start to use constructs like DataTypes to represent classifiers declared in a library things get are not so clear.  Also, when you are generalizations, and implementation links, the picture get cloudy when you start to use a third relationship to represent a super class relationships (not to mention that the derivation edge looks like an implementation link with bindings).  For these reasons the NetBeans UML module does not currently allow derivation edges to be drawn from a class to a template.  In the future when we have better support for libraries, we will probably add this feature into the tool.

Following are a few examples of how the Java generics are represented in UML. 

Example 1

The follow class declaration declares a class that extends a generic type.  The the super type is a generic instance of MyGeneric, with the argument of String.

public class MyExtendedGeneric extends MyGeneric < String >
{
}

The NetBeans UML reverse engineering module will create a class that extends a derivation classifier.  The derivation classifier will have a derivation to the MyGeneric template, and its binding will specify that argument is a String.

Example 2

The follow class declaration declares a class that implements a generic type.  The the super interface is a generic instance of MyGenericInterface, with the argument of String.

public class MyExtendedGeneric implements MyGenericInterface < String >
{
}

The NetBeans UML reverse engineering module will create a class that implements a derivation classifier.  The derivation classifier will have a derivation to the MyGenericInterface template, and its binding will specify that argument is a String.  For the use case the NetBeans UML module has actually extended UML.  In standard UML, an implementation link can only be created between a classifier and an interface.  However, in order to better support templates NetBeans allows an implementation to be created between classifiers and derivation classifiers as well.

Example 3

The follow class declaration declares a class that has one data member.  The type of the data member is an instance of the generic MyGeneric, with the argument of String.

public class MyClass
{
  MyGeneric < String > myAttr = new MyGeneric < String >();
}

The NetBeans UML reverse engineering module will create a class that has an aggregation association to a derivation classifier.  The derivation classifier will have a derivation to the template MyGeneric, and its binding will specify that argument is a String.

Technorati Tags: Modeling, NetBeans, Generics, Java, UML

Today I saw a very cool movie created from World of Warcraft scenes.  Check it out.

After ragging on MarsEdit about it's image support, I thought I better try out Ecto image support.

First thing I noticed it that I can drag an image from my filesystem (or even a web page) and drop the image into the editor.  I can also resize the image by clicking and dragging a resize handle.  Very cool.  I can also double click on the image and get a number of options.  For example I can specify that I want this image to be a thumbnail.  That is a nice feature.

I will now try to publish and see what happens.

The fact that Ecto posted my entries with a seemly random publication date, I have decided to continue my search for a good blog authoring tool. Today I am playing with MarEdit. MarsEdit seems to strive to be similar to an email client. The first thing that I notice is that MarsEdit does not have a Rich Text editor. You manipulate the HTML directly. While I like the freedom of modifying the HTML text, I would prefer to have a Rich Text editor.

Now MarEdit does have a combo box that list a number of HTML tags. By using the HTML tags tool, it does make it easy to add HTML tags. My main concern at this time is how to insert images. The HTML tags combo box does have a insert image item. So maybe it will help. Lets try it out.

So far so pretty good. I was able to select a picture and the pictures alignment. When I pressed the Ok button, MarEdit took care of sending the image to the server.

The image is a picture of my four children. The picture was taken the same day that my youngest son was born. August 25, 2006.

MarsEdit has a Preview option (so did Ecto). The Preview window has a live preview option. The live preview option allow you to see the entry in WSYWIG. The question I have is why not put that in the editor? Also after adding the image, I noticed that every keystroke I type in the editor cases the preview window to refresh. Which causes the image to redraw over and over. It was very annoying, so I had to close the window :-( . I have not turned off the live preview, and I notice that the image still flicker when I scroll the preview window. Very annoying.

Well now it the lime to publish.

Publishing Results Well the good thing is that the entry was published and immediately appeared. That is good. However, again the new line characters where not replaced with HTML line break tags. Before editing I thought that I set the option to convert line break to tags. I will try it again.

When I inserted the image, I specified that I did not want the image to have an alignment. I just realized that MarEdit defaulted the image to be left aligned. That is not good. I had to update the HTML by hand.

Well that did not work either. I just gave up and added the paragraph characters myself. All and All I like Ecto better.

One of my hang ups with blogging is a writing the blog.  You have to enter the blog into a text field a web page.  The problem is that you do not get nice editing tools.  Well at least I have not seen any editing tools.  So, I decided to see if there are any good blog editing tools.

I am testing out Ecto.  What is cool about using Ecto (maybe other blog tools as well) is that the entry editing feels like you are writing any other document.

Well this is my first entry using a blog editor.  Pretty cool.

Ok, I learned two things.  First, there is a delay from when you publish and when the entry appears in the blog.  The reason is that a publication time is set for the entry (why I do not know).  Second, you have to use the option edit setting "Convert line breaks in Rich Text mode" to automatically convert newlines to <p> and <br> tags.

Alright I have now updated my client about the time zone information.  Lets see if this works. 

Well that did not work.  Matter a fact, it seem random on when it will decided to actually post the entry. :-(

I have heard that people think that Domain Specific Languages (DSL) is a very abstract concept. Because of the abstraction, a lot of people are nervous about domian specific languages. I can see how people get that impression. In order to have a DSL, someone uses abstract concepts to design the language. The goal of a DSL is actually quite the opposite. The goal of domain languages is to move away from the solution domain details and embrace the problem domain. What I mean is that instead of talking in abstract concepts like Classes and Components, we start using the domain concepts (Car, Truck, Node, Project, etc) when developing software. Describing aspects of a system in concrete terms makes it easier to understand the system.

By no means is this concept new. If you look at the history of software engineering you will see steady progress of moving away from the abstract concepts to a more logical concept. First, we started with machine code. I would argue that the machine language is a very abstract language to a human, while the most concrete language to a computer. We then move to assembly language. Assembly language made developing a little more concrete to us humans by representing op codes (numbers) as names, but assembly was not understandable to a computer. Therefore, the assembly language program had to be assembled to machine language so that the computer could understand. The assembled program became the artifact. Next came structured language and functional languages. At first people said that these languages could never produce code as well as programs written by hand in assembly. Over time, this statement was proven to be incorrect, and the object code became the artifact. Next came concepts like object oriented programming and aspect programming. Over and over the process repeats. We move to a logical reprsentation of the machine code. Each iteration makes that programming language more abstract to the computer but easier to understand for us humans. Domain specific languages simply repeat the cycle. Trying to make it easier to understand the concepts needed to develop software.

The previous statements are all fine and good, but is there any practical use? Yes, there are a number of examples of domain languages out in the world. If you look at NetBeans you will see a number of examples. The one that everyone will be most familar with is the form editor. It is a language that is designed specifically for designing user interfaces. As such, it is very intuitive to use and very powerful. The reason it is very intuitive is because it uses the concepts of a user interface to describe the user interface. It does not use general programming concepts of classes and components to describe a user interface. The form editor uses buttons, panels, labels, and a host of user interface controls to describe a user interface. To build the same user interface in code is very possible, but it is a lot of work. It takes a lot of work to get the control in the correct locations, not to mention how to handle resizing windows. However, when you use the form editor, this becomes a farily trivial task. Especially a form editor like Matisse. Note that in the form editor a lot of code still needs to be written. It is still up to the developer to write the user interface logic. The fact that the form editor leave a lot of code to be written by hand is a very improtant thing to note. A domain specific language does not mean that there will no longer be a need for a good source code editor. The goal of a domain specific language is to start generating more code not to do away with writing code.

Another example is the orchrastration editor. The orchrastration editor is a graphical editor that is designed to write BPEL documents. The orchrastration editor is an example of a domain specific language that represents not structural information but instead behavioral information. Even thougth the orchrastration editor represents behavioral information, it is still easy to use. It is easy to use because it uses the concepts of the BPEL domain to describe the behavior that is to be executed.

In my previous examples of domain specific languages, I have used graphical languages. Domain specifc languages are not limited to graphical languages. Indeed, there are may example of textual domain specfic languages. BPEL is a good example of a domain specific language that is a text based language instead of being a graphical language.

I can already hear the arguments that BPEL documents can easily be represented in a general purpose language like UML. That is a very true statement. The UML Activity diagram would be a very good fit to represent BPEL documents. As a matter of fact, I have made that argument myself many times. Also, a page flow diagram can easily be represented as by a state diagram. The point is that the higher the level of the language, the more intuitive the language. Now, I am not saying that there is no need for general pupose modeling languages. I believe that general pupose modeling languages like UML can be used to represent domain specific langauges, but that is a topic for latter discussion.

So, where does that leave us? Are domian specific languages by its nature abstract? Well, the designer of a domain specific language has to think about how to design the language. Usally the designing of a language will take you into abstraction. I would argue that the level of abstraction required to design a language is no more than it would take to build the concepts into a modern object oriented application. For example, to write an accounting applicaiton you would still have to develop the concepts of the accounting domain into your system. You would instead use the accounting terminology as an abstract concept, and the object oriented concepts as the concrete concepts. With domain specific languages, the domain concepts become the concrete concepts. Therefore, putting the focus on the problem domain insteading of focusing on the domian of the programming language.

I have been tagged by Craig, and my goal is to quickly tag 5 others.

1. I grew up hanging wall paper in Dallas. I currently live in Denver, Colorado
2. I have 4 children, two daughters ages 7 and 3, and two sons ages 5 and 4 months. (yes we are now done)
3. I'm a die hard Dallas Cowboy fan.
4. I have worked on the same product what working for three different companies (Advanced Software Technology was bought out by Embarcadero, and then Sun bought the source code for Describe)
5. My hobbies are woodworking (not that I am not very good), and aquariums (I have a small 20 gallon tank).

Now to tag 5 more, Todd, Chris,Karthik, Sherry, and Matt

Today I came across an image of a tatoo. The thing is that the tatoo is the sun logo. This person really likes working at Sun.

As promised I am finally able to provide a flash demo of the new Accessibility features (You will have to press the next button to continue the demo). The demo will demostrates how to create model elements, and navigate a diagram via a keystroke. From what I have seen, we now have the most compliant accessibility support.

Later I will try to have a more in depth demo of model element navigation.

The UML development team has been working to add A11Y features to the UML product. What does this mean to our users. Well the first benefit is that we sill be able to satisfy the A11Y requirements, which is good. But the side effect is that our tool will have a lot of new keyboard access. For example, we have already added keyboard navigation in our diagrams. I plan to create a flash demo of our new navigation features. Stay tune.

Sorry that I have been away for so long. I will try to catch up a little. The UML module has been moved to NetBeans 5.5. Today, the module has finally been moved to the NetBeans 5.5 beta update center. In the this release the reverse engineering module is much faster. In our example applicatoin (which is the UML core module), we have over 3000 java files. We are now able to reverse engineer the module in around 6 minutes. That is a significant improvement over the previous releases.

We also have a new web report. In previous releases of Java Studio Enterprise, the web report was quite awkward to use. The new web report is much more easier. We have choosen to format our reports after JavaDoc.

On a sad note, we hav taken out live round trip. We decided to take out live round trip for a number of reasons. One major reason was because it did not work as well as we liked. Also, we where using the NetBeans Java Model, in NetBeans 6.0 the Java model will be taken out of NetBeans. The Java Editor will not be built on top of the Jackpot project. In the end NetBeans will have a much more robust editor (check out Jan Lahoda's blog about improved coloring, and about improved code completion), but for the UML team it means that we would have to rewrite our live round trip mechanism. Because of these two reasons, we decided that it would be best to take out the round trip component for now. In later releases we plan to put it back into the tool, but it will most likely take the form of a batch round trip instead of a live round trip.

We have also fixed a number of bugs, and worked on a number of usability features. Check out our NetBeans module web page.

Java Studio Enterprise 8 is now in Early Access. Java Studio Enterprise 8 has all of the great features that ship with NetBeans 4.1 and adds Developer Collaboration, Java Enterprise Profiler, and UML modeling. I will highlight some of the new UML features in Java Studio Enterprise 8.

UML Modeling Projects

One of the biggest enhancements to the UML module is a new UML project type. The UML project allows the user to either be in design or code generation mode. The design mode is used to support the Architect. Source code will not be generated while in the design mode. The code generation mode is designed to support developers. When in code generation mode, the source code and model will be sychronized.

UML projects are now embedded in the same Projects view as Java projects. Each UML project has three child nodes. The first node is the Model node. The model node is the root of the model tree. The model node is used to explore the model contents. The contents of the model node are identical to the project tree in Java Studio Enterprise 7.

The second node is the Diagrams node. The diagrams node is a diagram centric view of the model.

The third node is an Imported Elements node. Since multiple UML projects can now be open at the same time, model elements can be referenced between projects. The imported elements node displays all the model elements that are being refenced by a UML model.

Diagram Enhancements

A lot of work went into making the UML diagrams simpler to use. The first improvement is a simpler tool bar. The UML diagram tool bar now contains only tools that are applicable for all diagram types. The diagram specific tools have been moved to a new modeling palette. The palette has categories that are used to group related tool sets. Every palette has a Basic category. The basic category groups tools that are commonly used on the diagram.

Multiple palette categories can be displayed simultaneously. Each palette category can be collapsed to hide tool sets that are not being used. When a palette entry is selected, the tool remains active until the user exits the tool. The active tool is highlighted in the palette. The tool can be exited by pressing the right mouse button, the ESC key, or by toggling the active palette entry.



Source Navigation

Automatic navigation to source editor no longer occurs. A Navigate to Source context menu item has been added to model elements that is associated with a source file. The Navigate to Source context menu is available in the diagram and the project tree.

Diagram Image Export

A new Export To Image toolbar button has been added to the diagram editor. The export to image toolbar button is used to export the diagram to a graphic file. The supported graphic file formats are JPEG, PNG, and SVG.

Property Editor

The UML module now uses the NetBeans standard property editor which gives the UML module a consistent look and feel with Java Studio Entperise. The property editor no longer has multiple levels of properties.

I believe that UML is a low level modeling language. UML is great for describing the structure of an application. The sequence diagram and collaboration diagram is also very good at describing interactions between objects. However, in order for the development industry to meet the growing demands for our services, we need to describe applications using higher constructs than classes, interfaces and objects. For example, we need modeling languages that have constructs that describe a web service and an EJB. Once we have the higher constructs defined, the developer can drop a web service onto the diagram, plug in a few ports and BANG the web service has been created.

The previous paragraph sounds a lot like the Software Factories approach. The Software Factories approach creates a new language for each domain. The new domain specific language (DSL) is then used to describe an application. The advantage of the domain specific language approach is that you are no longer using classes, interfaces and objects to describe applications, you are now manipulating constructs that are custom fit for the specific domain that is being developed. As you have probably guessed the software factories approach will require the birth of a number of new languages. Each company that employs developers will also have to employ language specialists to develop and maintain languages needed for their specific domain.

In my opinion, I believe that the Software Factories approach has a lot of good points and a lot of bad points. One area that I disagree with is the break away from UML. I think that the higher constructs can be accomplished by either extending the UML meta model or by using the profile extension mechanism. In order to add the higher level constructs, the profile mechanism will need to be extended. One of the extensions that needs to be made to the profile mechanism is to allow a profile author to specify an alternative representation for a model element. Once "webservice" stereotype is applied to a component, the user will not see a component notation that has the stereotype of a "webservice." The model element instead will be represented as a web service. This concept is not to far fetched. Many UML tools already support the Robustness diagram notation. The Robustness model elements are UML classes that have a stereotype of "boundary," "controller," or "entity." The trick is that the representation of classes with the Robustness stereotypes is not the same as the representation of a class without the stereotype.

The way I see it, most users of modeling tools do not care about how the model element is represented internally. All they care about is how clear the information is represented, and how quickly they can get their work done. By still using an extension mechanism, the burden is moved from the language designers to the tool providers. The stereotypes that have their own representations can be added to a palette. A tool that adds the stereotypes to their palette can also allow the user to quickly drop model elements with the stereotype. The code generation mechanism (or model transformations mechanism) can handle the issues of transforming the classes with the stereotype to source code. Tools can do what ever it takes to limit the reasons why the user has to physically apply stereotypes to a model element.

Lets say that we have written DSLs for the EJB and web service domains. Now we need an EJB that is also a web service. With the DSL approach, we have to create a new language that merges the two languages which means the developer now has to wait until the language expert can create the new language. I would rather have the ability to overlay the concept of a web service onto my EJB object or vise versa. That way the developer would not have to wait for a new language to be created. Then, I could also view my object as a web service or an EJB depending on what the diagram is trying to communicate.

A domain specific language is extremely effectively for its designed use. However, as soon as you start to go beyond the bounds of the languages concepts the language starts to slow you down. Because of the limitations of the language, the developer will either fight the language, switch languages, or again go back to the language developer. In any case, the rate of development will be drastically hindered.

I believe that a shift in our thinking needs to be made. It is time for modeling languages to advance from low level languages to more abstract modeling languages. UML should become to modeling languages what assembly language became to modern programming languages. When it became too complex and too painful to develop using assembly languages, the industry started to develop more advanced languages. The higher level language would still compile down to the assembly language. For a long time the higher languages allowed developers to embed assembly language instructions into an application. More recently, programming languages such as Java and C# no longer allow the developers to embed assembly language instructions, and they no longer compile down to assembly language. The same pattern has to occur in the modeling world as well.

We need to build on top of UML to produce higher level modeling languages. We still need to be able to embed some UML constructs into the higher level modeling languages. The meta data of the higher level languages need to be built on top of the UML meta model, but few users of the modeling tools will know or care about how model information is stored. Just like few developers care what assembly instructions are generated when they compile their source files.

There are two reason why we should build on top of UML. First, UML is already accepted as the modeling standard. Second, UML already has the a powerful extension mechanism. The extension mechanism needs to be enhanced, but is still a very good mechanism.

There has been a dialog between Grady Booch and Alan Cameron Wills on the differences between using UML and DSL's (Domain Specific Langauge). After reading the two blogs, I had a lot of thoughts about the conversation, so I thought that I would share some of them here.

Alan asserts that with DSL you have a model that is designed around the domain that you are designing. In the example given by Alan, he states that when you retrieve the type from a DSL model, you will get the domain specific type name. In UML when you retrieve the type you get the abstract model element type, for example an UML Class. Grady counters the argument by stating that you get is a stereotype of with the domain specific type.

Both arguments are correct. When you read a UML model and you ask a model element for its type, you do receive a UML Class. Then you are able to receive the domain specific type by querying for its stereotypes. Now that I have stated how each argument is correct, I do not understand the point that Alan is trying to make with his argument. In both cases the model element information will have to be translated into some other form to actually produce source code. Whether or not the translation tool has to check for a stereotype or not, does not affect the user of the tool. Alan can be trying to make the argument that it is bad to require the user to add the stereotype to the class in the first place. I see this also as a tool issue. UML does not restrict tool venders from creating new representations for the UML model elements. An example is the Robustness diagram.

Most UML tools have some way to support the Robustness diagram. The model elements on the robustness diagram are specializations of a UML class. Since most UML tools provide special visualizations for Robustness diagram, the user is not required to add the Robustness stereotypes to the UML class.

While on the topic of stereotypes, Alan also states that "You have to understand all of UML (stereotypes,etc) before you can create your language on top of it". I personally can not imagine a way that you could possibly not have a complete understanding of a domain when you go to write a language. Even if you are wanting to write a new DSL you would have to be very knowledgeable about modeling languages. Basically this is not an area for the novice, even if you are writing a domain specific language. So, basically the choice is whether or not to build upon a system that has been used by a number of people, or whether you want to start from scratch.

Alan also makes a point that UML may not be the best choice to represents all domains, such as a visual GUI editor. I tend to agree with him on this point. However, I would also state that I think that the authors of MDA would also agree. OMG has spent a lot of effort designing modeling languages for other domains like data warehouse applications. In the book MDA Explained: The Model Driven Architecture -- Practice and Promise the authors talk about other model types. The sample application that is discussed in the book uses ER diagrams. I am not saying that I do not have any problems or concerns with MDA, for example in MDA Explained the ER diagrams are generated from a Class diagram which I do not see as a realistic approach.  In reality the developer will most likely be given the ER diagram from a database management group.  It will be the developers job to retrieve the information from an existing database instead of designing a database.