Posts tagged model-driven
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.
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.
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).
Sex and Drugs and Software Architecture
Nov 30th
Yeah, right. Software Architecture not only sounds boring, in fact it is boring.
Software Architecture is all about structure. The more structure the better. That makes software architecture boring. (Not for me, I like creating structure)
But is structure always necessary? Maybe not. Sometimes, a monolithic application without extensive structuring will do just fine.
If you are not from under a rock, you probably know what is a layered architecture. Nowadays it seems that everyone wants a layered software architecture, it is a must have. But do they know why? The people who want the layered architecture most are not able to explain why they prefer a layered structure.
And do you need a layered architecture when the code is generated from a model?
I am not sure. You can start simple and reuse the same model as the generation process evolves and generate a full blown loosely coupled layered application.