Archive for the ‘MDA’ Category

When UML meets Slashdot…

Monday, June 2nd, 2008

There was a recent thread about UML on Slashdot, as a reaction to this blog post . The headline: “Is UML Really Dead, Or Only Cataleptic?“. Many posters are clearly bitter towards UML. There seems to be a strong preference for using UML as a communication tool as opposed to as a basis for partial or full code generation (see post on UML modes). Many also complain that the graphical notation is cumbersome and that it hurts productivity (+1!). A few actually like UML; however, it is said that the UML specification is vast and complex and that you should pick the parts of UML that make sense for your case/goals (+1 here too).

Lots of interesting points, but the most negative posts are just misinformed. But that is Slashdot, what should I expect? Java and Eclipse have, in general, a poor receptivity on Slashdot, so I guess UML is in good company.

Of course, while I disagree with those that ditch UML because it was not properly employed in some project they worked, I strongly agree with the complaints about UML (graphical) diagrams being cumbersome and hard to deal with, as I have written here before. But that is not a problem with UML per se, but with the fact most still see it as a graphical language.

UML certainly has its share of problems (design by committee, no reference implementation), but I strongly believe it is very useful and that there isn’t anything out there (I am talking to you, home grown DSLs) that can replace it as the lingua franca for model-driven development.

M4 has left the building!

Tuesday, May 6th, 2008

M4 has been declared. If you got the M4 test build that was announced a week ago, no need to download again, it is the same build. Please see that post for a summary of the changes.

The TextUML tutorial has been updated in order to reflect the changes that happened during M4, the most remarkable one being that starting with M4 there are no built-in packages (such as ‘base’ and ‘base_profile’) any longer, other than those defined in UML2 itself. So if you were using elements defined in those built-in packages, you have now to define the elements yourself. The rationale is that the TextUML Toolkit should not be in the business of providing built-in packages nor rely on anything other than standard UML to do its work.

If you didn’t get the test build, go ahead and download M4. If you want to see a feature in the TextUML Toolkit, now it is the time to ask, as the next milestone will be feature freeze. And if you have tried the Toolkit and decided it is not for you, we would die to know why. Your feedback is greatly appreciated.

“Why we write code and don’t just draw diagrams”

Monday, May 5th, 2008

TextUML is a textual notation for UML. The TextUML Toolkit is an Eclipse-based IDE-like tool for creating UML models using the TextUML notation.

Other tools follow the same approach. Emfatic (now an EMFT subproject) has been doing the same for EMF Ecore for a long time; the TMF project aims to be for textual modeling what GMF is for graphical modeling, and will be based on GMT’s TCS and xText components.

Still, people are often puzzled when I explain what the TextUML Toolkit is. A common question is: “if I am going to write code (sic), why do I need UML anyway?“.

Dean Wampler from Object Mentor wrote on his blog a while ago a post entitled “Why we write code and don’t just draw diagrams“. It is a short post, but he presents very good points on why a graphical notation is usually not suficient and is bound to be less productive than a textual one when it comes to modeling details. For instance, on the saying “a picture is worth a thousand words“, Dean wrote:

What that phrase really means is that we get the ‘gist’ or the ‘gestalt’ of a situation when we look at a picture, but nothing expresses the intricate details like text, the 1000 words. Since computers are literal-minded and don’t ‘do gist’, they require those details spelled out explicitly.

Couldn’t have said it better.

I strongly advise you to read the original post in its entirety, but I will leave you with another pearl from Dean’s post (emphasis is mine):

I came to this realization a few years ago when I worked for a Well Known Company developing UML-based tools for Java developers. The tool’s UI could have been more efficient, but there was no way to beat the speed of typing text.

Enough said.

TextUML Toolkit M4 test build is now available

Monday, April 28th, 2008

The first (and hopefully only) test build for M4 is now available. This is the first milestone where you can get the TextUML Toolkit via Update Manager. Just point Update Manager to:

http://abstratt.com/textuml/update/

Actually, if you are planning to use Acceleo or UML2Tools, it is the best approach. From an Eclipse SDK 3.3 install, point the Update Manager to the site above and install the TextUML Toolkit along with its prerequisites (EMF and UML2). Once you are done, you can install any compatible tools, such as Acceleo and/or UML2Tools (sites will be automatically configured after you install the Toolkit and its prerequisites). If you are not planning to use Acceleo, you can start from an Eclipse Platform install, or you can just download the TextUML Toolkit from the download page as usual.

Follows a summary of the changes that went into M4, including features (in bold) and bug fixes.

Ticket Summary
49 prevent creation of duplicated symbols
102 NPE trying to set value for stereotype property
143 declare a built-in update site for the textuml toolkit
145 project creation wizard issues
164 Support nested packages in TextUMLRenderer
165 Unexpected exception while compiling - java.lang.IllegalStateException: deresolve relative URI
166 spurious empty null.uml or base_profile.uml files being created
168 integrate a code generator
169 constant literal assignment is broken

I will be writing on some of those features in following posts.

Rafael

TextUML Toolkit is now available on multiple platforms

Monday, March 3rd, 2008

The latest milestone (M3) of the TextUML Toolkit has been declared today, as promised earlier here. As I said before, the focus for this milestone was stability and performance, so you can expect a much snappier and more solid tool. But it also includes some cool new features:

  • you can drop UML2 models created elsewhere into a MDD project and you can use them from your TextUML code as you would with models created using the Toolkit
  • you can even decompile a UML2 model and read it using the TextUML syntax with the TextUML Viewer (which takes over as the default editor for *.uml files)
  • you can auto-format the current compilation unit with Ctrl-Shift-F
  • and last but not least: Linux and Mac OS X (Power PC and Intel) are now supported

The main reason for this focus on performance and robustness is that the tool must be something that people can rely upon and become productive with. From now on, real user demand must drive the addition of any new features and bug fixing efforts. So now it is your turn. Download the TextUML Toolkit and start using it for creating your UML models. It is free! If you like the approach of modeling using a textual notation, I am sure you will enjoy it. And even if you haven’t bought the idea yet, give it a try. I would be more than glad of hearing your suggestions and opinions. And more importantly, will make sure that any problems reported will be promptly addressed.

Looking forward to your comments, either here or by e-mail on the Abstratt forum. Cheers.

Rafael

TextUML Toolkit M3 test build is available!

Thursday, February 28th, 2008

A TextUML Toolkit M3 test build is now available from the download page. If no serious issues are found in this build, it will be declared the final M3 build later this week.

The focus for this milestone was to improve the performance, memory footprint and stability of the tool, and very good progress was made in those areas. But there are also some brand new features, mostly in the area of integration with existing UML models. You can now safely add existing UML2 UML models (built elsewhere) to the project root and they will become available to the textual notation. Another cool feature in this area is that you can now double-click any existing UML2 UML model and read it using the textual notation (think “UML decompiler”). See below the sample model from Getting Started with UML2 in both textual and graphical notations:

click for a full screenshot

Would you like to take a look? Grab the M3 test build, and give it a try. Please report here any problems and leave your comments. As usual, your feedback is really appreciated.

UPDATE: If the diagrams don’t show and everything else seems to work, you probably need the Visual C++ Redistributable package from Microsoft. This is a limitation that seemed to be recently introduced with the Graphviz support on Windows and the Graphviz team is looking into this issue. Sorry for the inconvenience.

Rafael

Textual notations and UML compliance

Thursday, February 7th, 2008

One common misconception is that UML is a graphical language and that any tools adopting alternative notations (such as a textual one) are inherently non-compliant. That can’t be farther from the truth. Read on to understand.

The fact is that the UML specification clearly separates abstract syntax (the kinds of elements and how they relate) and semantics (what they mean) from concrete syntax (what they look like), and states that there are two types of compliance:

  • abstract syntax compliance
  • concrete syntax compliance

Concrete syntax compliance means that users can continue to use a notation they are familiar with across different tools. This is important when UML is used as a communication tool in a team environment. Architects, designers, programmers and even many business analysts speak the same language.

Abstract syntax compliance means that users can move models across different tools, even if they use different notations. This is essential when UML is used as a basis for model-driven development. You might want to use tool A for creating the model, tool B for validating the model, tool C for somehow transforming/enhancing the model and tool D for generating code from it (a common form of MDD tool chain).

The TextUML Toolkit uses a textual notation that strictly exposes the UML semantics, but it is not compliant with the language concrete syntax by any means. On the other hand, the toolkit uses Eclipse UML2’s XMI flavor for persisting models and thus is fully compliant regarding the abstract syntax. That is consistent with the vision for the product: a tool from developers for developers that want to build software in a more sane way: the model-driven way. Developers can create models using a notation they are more productive with. Models can then be used as input for code generation using many of the tools available in the market. If non-developers might frown upon a textual modeling notation, they will always have the option of using their favorite graphical-notation based tools for reading the models. I mean, if their tool of choice is abstract syntax compliant as well.

Eclipse DemoCamp in Vancouver

Saturday, December 8th, 2007

Last Thursday happened the 1st Eclipse DemoCamp in Vancouver. It was a very dynamic event, with nine short talks packed into little more than one and a half hours. Attendance was high, I was really amazed to see such a great turnaround. The audience saw a diverse range of interesting Eclipse-based projects being developed in Vancouver/Victoria.

I demoed the TextUML Toolkit and got good feedback and some very interesting questions. The idea of a using a textual notation for creating UML models is still not a very easy sell, and that continues to surprise me. Being a developer, I find working with a textual notation so much more natural than a graphical one that it makes it hard for me to see things from other people’s shoes. I plan to go over the issue of textual versus graphical notations on a future post.

All in all, it was a great event. Many thanks to Tasktop’s Robert Elves and Mik Kersten for organizing it, to the Eclipse Foundation for sponsoring the event, and congrats to all presenters.

The two EMFs

Saturday, December 1st, 2007

In a recent thread on the EMF newsgroup, I came to realize that there are (at least) two EMFs, each belonging to a different class of product, and attending completely distinct requirements.

EMF’s native metamodel, Ecore, is a generic, lean object-oriented metamodel based on a subset of UML.

EMF’s runtime framework provides Java applications with runtime support for object models “including change notification, persistence support with default XMI serialization, and a very efficient reflective API for manipulating EMF objects generically” (source).

I am a happy user of EMF’s Ecore metamodel as a poor man’s UML (EMF team, please take that as a compliment). From Ecore-based models, using a compatible template engine, I can generate all code/artifacts that are prone to automation, be they Java code or not.

The runtime aspect of EMF is certainly useful to many applications, but certainly not to all or maybe even most. That is not to say that the EMF runtime does not provide a lot of value, as it clearly does given its popularity. Nor does it imply that the EMF runtime API has design flaws that prevent its use to be more widespread. The fact is that frameworks, while designed for extension, always impose a certain set of architectural decisions in order to provide value out-of-the-box. Those decisions are bound to make its use more suitable to some scenarios and applications than others. The goal is to make as many people happy as possible. It is clear that the EMF team has pulled off that trick. But that does not mean that using EMF-generated model code is appropriate for every Java application out there.

Model driven development maximizes reuse via a complete separation between problem domain and technological concerns. This separation is critical to allow us to build software in an obsolescence-proof way. EMF’s Ecore provides a good foundation for MDD in this sense, regardless the technology choices for the software being developed. The EMF runtime framework, albeit a valuable tool for a significant range of applications, brings with it a specific set of choices in terms of design and implementation decisions, and as such has a less universal applicability.

However, time and again I read comments in the EMF newsgroup that lead me to believe that this duality might have been accidental, and that the sole reason Ecore was created was to support the generation of Java applications based on the EMF runtime. If that is really the case, this is something that both amuses and worries me. My concern is that if the EMF team does not acknowledge the importance of Ecore as an independently useful product, technical decisions in the evolution of EMF might break the use of Ecore in contexts other than EMF-based Java applications.

UML 101 with TextUML - Profiles and Stereotypes

Thursday, September 6th, 2007

Profiles and stereotypes form a lightweight mechanism for extending the UML metamodel.

A stereotype allows you to tag elements in your model so they can be interpreted differently from ordinary model elements, much like annotations work in languages such as C# and Java. These tags can then be used to drive code generation, for example, so for every class marked as “persistent”, appropriate persistence code should be generated.

A profile is a special kind of package intended to contain stereotype declarations that extend UML to cover some specific domain or platform.

Let’s see how to declare and use profiles and stereotypes with the help of the TextUML Toolkit.

Declaring a stereotype

To declare a stereotype in TextUML, one uses the following syntax:

profile <profile-name>;

stereotype <stereotype-name> extends <metaclass-1 [,...metaclass-n]…]
[<property-1>; [... property-n;]…]
end;

end.

In other words, a stereotype can be declared as applicable to one or more metaclasses (i.e. types of elements in a UML model), and a stereotype can optionally declare properties (more on properties later) . For instance, a classes could be tagged with the <<persistent>> stereotype:

profile business_apps;

import uml;

stereotype persistent extends Class
end;

end.

Or operations could be marked as <<transactional>>, meaning that a transaction will be started whenever the operation starts executing, and finished when its execution ends:

profile business_apps;

import uml;

stereotype transactional extends Operation
end;

end.

Any UML element can be affected by stereotypes, but stereotypes are declared as targetting (potentially multiple) specific element types. For instance, the UML specification has an example of a profile for Enterprise JavaBeans that defines a <<Session>> stereotype for session beans. The<<Session>> stereotype declares a property that allows modelers to define whether the session bean component is stateful or stateless.

profile EJB;

enumeration StateKind
  STATELESS, STATEFUL
end;

stereotype Bean extends uml::Component
end;

stereotype Session specializes Bean
  property kind : StateKind;
end;

stereotype Entity specializes Bean
end;

end.

Applying a stereotype

Now that we know how to declare stereotypes, lets see how to use them. First of all, you must apply the profile defining the stereotypes to the model declaring elements you want to apply stereotypes to:

model bank;

apply business_apps;

/* other model elements here */

end.

You can then attach stereotypes defined in the applied profile to the suitable model elements in your model:

model bank;

apply business_apps;

[persistent]
class Account
    attribute accountNumber : base::String;
    attribute balance : base::Real;
    attribute changes : AccountChange[0,*];
    [transactional] operation withdraw(amount : Real);
    [transactional] operation deposit(amount : Real);
    operation balance() : Real;
    [transactional] operation transfer(other : Account, amount : Real);
end;

end.

In the example above, we applied the <<persistent>> stereotype to the Bank class, and the <<transactional>> stereotype to the withdraw, deposit and transfer operations. In order to have access to these stereotypes, we had to apply the “business_apps” profile to our model.

Conclusion

In this post/article on UML basics using TextUML, we saw how to declare stereotypes and apply them to elements in UML models. We learned that a stereotype must explicitly declare the metaclasses they are applicable to, and that optionally stereotypes might declare properties. Finally, we saw that before a stereotype can be used in a model, the profile declaring the stereotype must be applied to the model.

TextUML Toolkit 1.0 M2 test build is available

Wednesday, August 29th, 2007

A TextUML Toolkit 1.0 M2 test build is available off the download page. If no serious issues are found in this build, it will be declared the final M2 build later this week.

The key feature developed for this milestone is the graphical class diagram viewer, which reuses the EclipseGraphviz project. The viewer shows a live representation of the UML model built from your TextUML source file using the standard graphical notation. It can also be used to visualize UML files created by any UML2 compliant tools.

textuml-toolkit-10m2-small.jpg

Other significant change is that the “extends” keyword is now used specifically to state the metaclass a stereotype is a applicable to, whereas “specializes” should be used for class inheritance. This was for a better alignment with the official UML terminology. Finally, there is now support for declaring enumerations.

Would you like to take a look? Grab the M2 test build, and give it a try. Your feedback is much appreciated.

RC

Full code generation from UML class, state and activity diagrams

Friday, June 1st, 2007

UML has become the lingua franca for modeling applications using the object-oriented paradigm. People use UML in many different ways (see the post on UML modes), ranging from as a communication tool to as a full fledged programming language that supports full code generation. This last way of using UML should puzzle most readers - how can UML models lead to full code generation?

UML has two diagrams that are used for behavior specification: the activity diagram and the state diagram. These two diagrams (more one than the other, depending on the nature of the subsystem being modeled), plus the class diagram (for modeling the structural aspects of the object model) provide the framework that supports the design of complex applications in a way that is fully complete (and thus allowing 100% code generation) while still implementation independent (see earlier post on platform independence). All the other diagrams (use case, sequence, collaboration) are interesting for gathering requirements, but are useless in modeling a solution that can be automatically transformed into a running application, and thus we will ignore them here.

Specifying structure with the Class Diagram

The class diagram is the most well understood of all diagrams in UML. You can model all structural aspects of your object model in the form of classes, attributes, operations and relationships between classes. This specification of structural aspects can then be used for generating (boilerplate) code, database schema, configuration files and so on so forth. This is great already, as that is most of the work. But without including behavioral aspects, it is impossible to do full code generation solely from the class diagram, you are forced to fill the empty methods with handwritten code (unfortunately this is how most vendors expect you to do model-driven development). Still, the class diagram is a fundamental one in which it provides a base framework the other diagrams can build upon.

Specifying dynamics with the State Diagram

The UML state diagram (derived from David Harel’s state charts) allows for a full design of the dynamic aspects of a system. One can model complex state machines using the state diagram, always in the context of a class described in the class diagram. Many mainstream applications do not have any interesting dynamics though, so in those cases the state diagram has limited value. However, in applications for certain industries (such as robotics, telecom and automotive) it is the most important diagram.

Specifying business logic with the Activity Diagram

The most underrated of the UML diagrams, the activity diagram has a key role: it is the only one to allow the modeler to specify behavior in a precise way. The Activity Diagram provides elements (such as actions, pins, data and control flows, signals) that allow specifying the meaning of a behavioral element (such as the body of an operation from the class diagram, or the effect of a state transition from the state diagram).

But no matter how important the UML activity diagram is, it has one strong limitation: it demands too much detailed information in order to be fully defined (and thus actually useful in the context of code generation). Any simple logic that could be written in a few lines in, say, Java, requires a graph with so many nodes that it is virtually impractical to use it with the graphical notation, severely hampering its more widespread adoption.

Have I just suggested that activity diagrams are useless for any serious usage? No! It is just the case that the graphical notation is too cumbersome, and it is not just a problem with the specific choice of symbols - there will never be any graphical representation that can be as expressive and concise for specifying behavior as your programming language of choice (even if your favorite language is as verbose as COBOL). So it is a matter of representation: a textual notation is much more appropriate than a graphical one. The activity diagram itself is fine, thanks.

So what is the textual notation for the activity diagram? There is none. I mean, not one defined by the OMG. Many companies have defined their own action languages (such as Pathfinder AL, Bridgepoint OAL, Kennedy Carter’s ASL) with compilers that provide a textual front-end for the UML activity diagram. TextUML itself has a bigger cousin (currently an ongoing work) that allows specifying UML activities in a way that is familiar to any programmer. Want to see what an action language looks like? Expect a new post on the subject (including our very own action language) here soon.

MDA blogs (and other resources)

Thursday, May 31st, 2007

Just started a page for collecting links to interesting blogs (and other resources) on MDA, UML and model-driven development in general. Check it out

Model-driven development improves reuse

Wednesday, May 30th, 2007

One notable benefit of model-driven development that is often underrated is improved reuse. This is a direct consequence of appropriate separation of concerns promoted by this development approach. The more intertwined concerns are when addressed in a piece of code, the harder it is to reuse that piece of code. The reason is simple: whenever you tie a solution for one concern to a solution for another concern, you are in trouble: you cannot reuse that piece of code where only one of the concerns is relevant, or the solution for one of the concerns is not appropriate (even if the solution for the other concern is).

Model-driven development promotes an approach where problem-domain concerns are addressed separately from implementation concerns. That means artifacts dealing with problem-domain concerns are free from any specifics on target platforms, and also that artifacts addressing implementation-related concerns are totally unaware of any problem domain knowledge.

That is fantastic, and the reason is twofold:

  1. it makes it viable to build a repository of platform-independent problem-domain specific components, likely created by people that are experts in their domain, that can be reused on different target platforms;
  2. it allows implementation specialists to code their technology-specific implementation strategies as standalone artifacts (i.e. templates), which can then be shared and reused in applications for the most varied problem domains.

The software industry has been looking for a long time for a way of encapsulating knowledge about specific problem domains in the form of platform-independent software components. Model-driven development with true executable models enables that dream.

For many decades, valuable business logic has been imprisoned into obsolescence-prone implementation-specific artifacts. We are working hard on a product that will help stop this insanity and finally make the dream of truly reusable component repositories a reality.

Platform independence in MDA

Tuesday, May 22nd, 2007

One key aspect of MDA is platform independence. However, even some of the brightest people in our industry misunderstand what platform independence means in MDA.

Platform independence has a different meaning in MDA than it has, for instance, in Java. Java promotes platform-independence by providing a common environment that insulates the application from platform details such as the instruction set and system API (for instance, for memory allocation, file system manipulation, networking, GUI, threading, etc). The application still has to address all these concerns, but it does that through API and mechanisms that work the same way regardless the actual underlying platform, and thus can run on any platform the Java environment is available. In other words, the Java environment is the platform.

MDA promotes platform-independence by adopting a design-centric approach. Models are removed from implementation related concerns and thus are inherently platform independent: a single design can be reused for building the same system for multiple target platforms. The implementation details are taken care of by target platform specific templates. The templates are applied to the user models then generating concrete platform-specific artifacts (running code, documentation, database schema, configuration files). Differently from Java (even if Martin Fowler says so), MDA does not promote another platform. What it does is to promote a clear separation between problem domain concerns and implementation concerns (as covered before here in the inaugural series entitled “Where we are coming from“).

The benefits of this separation are many: from unprecedented levels of reuse to better opportunities for work specialization. I plan to cover these benefits in detail on future posts.

RC

UML modes and tools

Saturday, May 12th, 2007

In his bliki, Martin Fowler eloquently describes the three different modes in which UML can be used: UML as sketch, UML as blueprint and UML as programming language. Let’s revisit the different modes from the perspective of tools for the job.

UML as sketch

Description: In this mode, UML is essentially a tool for conceiving and communicating ideas between team members. As such, there is no need for completeness or validity of the object models, and actually any information not essential for communicating the idea at hand is intentionally omitted for conciseness and clarity. UML as sketch is increasingly popular, even at shops where model-driven development is considered an abomination.

Tools for the job: developers don’t need special tools for using UML as a sketching tool, paper and pen or a whiteboard are great. The only flaws are when you would like to archive a drawing or send it to others by email. In that case, Visio (or any other generic diagram editor) is a common choice. Another less known option is Whiteboard Photo, that allows you to take a snapshot of your hand drawings (on a whiteboard or on paper) and have them automatically translated into great looking clean 2-D charts.

UML as blueprint

Description: in this mode, the focus is on having UML models used as an input to the implementation phase, and thus need to be valid and complete from the point of view of structure. Behavioral aspects are described in textual form (such as in use case descriptions) or by means of diagrams depicting scenarios (such as sequence or collaboration diagrams) and are inherently informally and incompletely described. The models can be submitted as input to code generation but the generated code has to be enhanced by hand to cover the behavioral aspects.

Tools for the job: generic tools won’t cut it here - you will need diagram editing tools that support all (or most) of UML diagrams, and (if you are taking the code generation route) persist your models in a format that your code generation tools can understand. Most UML tools out there support (or intend to support) this.

The TextUML Toolkit we provide supports this mode too. Your class diagrams are fully verified, and are persisted using a standard format.

UML as programming language

Description: In this mode, UML models must be complete both structurally and behaviorally as they must be simulatable and serve as input to code generation (by the way, Fowler really misses the point when he argues that a graphical language such as UML is not appropriate for fine grained behavior specification - who said UML is graphical anyway?).

Tools for the job: there are only a few tools currently in the market that support this mode, they tend to target embedded software development, and I bet you will not find how much they cost on their websites unless you call them.

Corcova Libra will support this, and when made available will visibly sport a reasonably fair price on our web site. Also, Libra will aim at mainstream business application developers, instead of focusing on specific vertical markets.

Conclusion

UML as sketch is cool and useful, but from the point of view of software engineering (our focus here) is meaningless.

UML as blueprint is increasingly practiced in shops where (partial) code generation has been adopted. It has benefits over writing the entire code by hand, but it still requires all the interesting code to be written manually, and there are a lot of issues with that.

Finally, UML as programming language (in other words, full blown model-driven development) is the most interesting of the three modes, even if there is a lot of skepticism and misinformation towards it. I will talk about that in an upcoming post.

RC