Zen Architect.NL (Henk van Dijken)
the art of model-driven code generation
Extracting Business Knowledge From Data Models
Mar 4th
Recently, I was following a discussion on extracting business knowledge from UML models. UML models, UML models, and more UML models.
Slowly a thought was emerging from my soaky brain:
hey dude, data models are models too.
In fact, a data model doesn’t always have to be represented by an ERD diagram.
It is also very feasible to diagram a data model using UML class diagrams. It even gets better when you stereotype your classes <<table>>. This enables code generation software to automagically recognize the stereotypes and – for example – generate SQL script for you.
Why on earth that could be remotely interesting?
Because your model is independent from its physical representation.
This way, you can “extract” a model from the physical database, introduce some enhancements, and re-apply the enhancements to the original physical database.
It enables you to enforce an uniform use of naming conventions.
“El Cheapo” Likes It Cheap!
Mar 1st
Ever heard of “El Cheapo”? It’s very Dutch.
El Cheapo likes cheap. That is, very cheap. Even when cheap is compromising quality, El Cheap still likes cheap. Did I mention the word cheap?
So, back to software development. El Cheapo likes Quick & Dirty!
The problem with software quality is that is does not pay-back right here and right now. Therefore, it takes strength to adhere to software quality principles. Often it feels like: No pain, no gain.
Remember, lack of quality is like a boomerang. It always comes back, especially when you least expect it and definitely do not need it. A bad bargain is dear at a farthing.
My advice is: as soon as you discover an El Cheapo amongst your midst, go neutralize it with more expensive decoys. As soon as El Cheapo senses the decoys, El Cheapo baits and wants to cheapify them.
Geeky Book Review – Henk’s Book-Case
Feb 12th
Looking at my collection of technology books immediately two things pop up in my mind:
- I really read a lot of paper books, which is very undigital.
- Some are really ancient (pre-Y2K bug), maybe its time to let go some of them. Auch.
I see a lot of UML and pattern books. Refactoring. And books on RUP of course. Those are definately not going somewhere. Hmm, maybe I should order another one on that topic.
But I also see a lot of different technology books, like WWF, WCF and WPF. A weird thing is that I do not own a book on Silverlight, but I do own a couple of books on CSS (and patterns).
And… Ah, there they are. The really old books. MySQL/PHP book. Some other old books. And what do we find under this dust…
What a beauty: C++ Builder 5 Developers Guide (2001).
Maybe I should intall C++ Builder in a virtual machine and have some fun.
See you later!
Model-Driven Code Generation Process
Jan 23rd
The model-driven code generation process is really simple.
You create a model, for example using UML. Next, you feed a hungry generator with your model in a format it can digest. That could be XMI.
The model-driven generator (MDG) transforms your model into code using a template of some kind. Here it outputs C# code that can be compiled into an assembly using a c#-compiler. You also will need some framework or platform to run your code.
The hard part is creating a good model.
Silverlight & WCF RIA Services
Jan 14th
Yes, I like Microsoft Silverlight 3.0+. Why?
Not because of its flashy look. Not because of the abundance of (custom) controls, for example as showcased by the Blacklight Showcase or Microsoft Silverlight Toolkit.
Even not because of Moonlight, for bringing Silverlight to our nerdy linux friends
Nope, it is because of the introduction of .NET RIA Services which enables you to expose your business logic and data through WCF technology.
I like this client-side polish for its solid data-driven architecture.
SmartDraw vs. Dynamic Draw!
Jan 8th
To be honest with you: I am a Visionist.
I really like Microsoft Visio. I do. I use it a lot, but from a functional perspective I use a very narrow portion in respect to different diagrams available.
I almost always start with a Flowchart and extend it into something I like. Before I discovered StarUML, I modeled UML diagrams using Visio Stencil and Template for UML 2.2
Thus it was time to do some research i.e. query “alternative to visio”. Of course, there is Dia. To be honest with you, I find it a little bit… premature. I looks even premature on Ubuntu.
Other candidates are Dynamic Draw and SmartDraw. Dynamic Draw is open source, and for SmartDraw you need an open wallet.
First look at Dynamic Draw.
Although I find the user interface a little bit harsh, I do like Dynamic Draw. It has a rich functionality. It even has the ability to “Borrow Shapes from Visio”. No kidding.
A harsh, but perfect drawing suite.
The reverse is true with SmartDraw.
It has a really appealing user interface and a very large amount of shapes you can draw with. It also has a WPF-look. Nice, nice, nice. And you can import Visio, but you must have Visio installed.
I almost bought it, so slick it is….
But – unfortunately – it sucks. I hate to pay for buggy programs…
Just an example:
Conceptual and Storage Model
Dec 27th
The most common model is the data model. Deep in the application architecture a physical model can be found, which is a straight representation of the database (ERD diagram).
More superficially, in the core of the application architecture, a conceptual representation of the same data model can be found (UML diagram). However, it should be kept in mind that both are derived from the same underlying data model, thus are essentially the same. As a result mapping from one to another is relatively straight forward (Data Source Explorer).
Model-Driven C# Development with Java-tools
Dec 19th
Did you ever used Eclipse? Never? Then, now is the time!
Lets generate some crap…
- So, first we need Eclipse. Next, install the open-source modeling tool Topcased and code generator Acceleo into Eclipse.
- Next, spend a couple of hours in finding out how it all should work together.(To be honest, it didn’t take hours but – that’s why I don’t like using Eclipse – it took me too long to configure and make it work)
- Model something (*.umldi), for example a silly 101 school model. You see them often, especially here.
- Create a stunning generator-template (*.mt)
- Generate some code (*.cs), and finally
- Compile the generated code in your – and mine, of course – ***favorite*** integrated development environment. Wow, man. I created real compilable C# code.
Thus, nice work.
Reusable Thought Patterns
Dec 10th
Yes, indeed. I just invented reusable thought patterns.
As you probably know, design patterns are recipes for solving common software design and/or development problems. The same holds true for architectural problems.
But how would you tackle a recurring problem that cannot be solved by a pattern?
You could call it a practice. That’s a good one. But that’s not exactly what I mean.
What I am talking about is the gap between action and reaction. The gap that is filled with mindful thinking.
If you are exposed many times to a certain action or situation you probably will react in a similar way every time. You don’t have to think about it profoundly anymore.
You could say that you get into a rut, but I call it a thought pattern.
The first time when something happens, you have to think about how to react properly. You react, but probably it doesn’t work out quit well. The next time when a similar thing happens, you have learned from the first experience and try something different. Over time, you fine tune your reaction. It gets better and better.
Finally, you don’t have to think long how to handle the event. That’s what I mean with a thought pattern.
How-to Model Software Architecture
Dec 3rd
With software architecture my rule of thumb is: less is more. I like lean.
Developers – your primary audience – should get a good hunch of the path they must walk, but it should not be written down in such detail that it freezes their thinking organ.
Therefore there is no room for micro-managers or control-freaks when it comes to modeling software architecture.
Some diagrams should be enough. Additional text is in place to explain the diagrams in a concise matter. In this I like the “4+1” Architectural approach.
I am not sure about you, but personally I don’t like those bloated documents with many pages, but low information density.
A software architecture document should also bring in ***technique***. It should be more than just rephrasing user requirements.