Soluta.Net

UML Rorschach Diagram!

2011-09-14T10:00:00.003+02:00

I think I will make a submission to the OMG, a new diagram is needed in the forthcoming 4v of UML: the Rorschach Diagram! Like a Rorschach Test, you can put boxes an lines randomly in the diagram and let users perceive the semantics they want. Very useful to create UML models quickly not caring about the semantics that will be created by readers. They will also see what they want to see, and usually it's the solution they seek for their problems.

Best wishes, without frills

2010-12-24T13:50:00.001+01:00

Best wishes, without frills, to all my friends, no video or pictures attached.
Best Wishes for Happy Holidays, not limited to just a few days: Best Wishes for the entire 2011,
Best Wishes to those who love me, and who does not because we all deserve a hope for better days, serenity and health.
Best wishes for those who have lost their jobs, who just found a new one and who is struggling to keep it.
Best Wishes to our grandfathers and grandmothers that with their babysitting are supporting the parents that have full time jobs.
Best Wishes to our politicians, who perhaps are now marketing oriented, but nevertheless I wish the best to all of them: I Wish they find a better way to lead Italy, maybe thinking less of their interests and of their leader.
Best wishes to the future generations, to the parents who grow them up, trying to instill an honest education and a direction in life.
Best Wishes to prisoners, for those that tries to redeem their-self and those who can not, hoping that prisons are not only a place for suicide and conviction.
Best Wishes to those who have suffered a death in their family, and to those who have created a new life, joy and suffering are very close that almost touch.
Best Wishes to the immigrants, that are not different from our grandparents or grand-grandparents who emigrated with a cardboard suitcase in Argentina, Canada and United States of America.

Best Wishes to those of who love each-other, to those seeking a partner and to those of you who did not find one yet.

... and some Best Wishes and Cheers also to me

Pierfranco

Auguri

2010-12-23T14:27:00.002+01:00

Auguri, senza fronzoli, a tutti i miei amici, senza video o immagini.
Auguri di Felici Feste, ma perché limitarci a pochi giorni: Auguri per tutto il 2011,
Auguri a chi mi vuole bene ed anche a chi non me ne vuole perché tutti meritiamo un Augurio di tempi migliori, serenità e salute.
Auguri chi ha perso il lavoro, a chi lo ha trovato e a chi se lo tiene stretto con i denti.
Auguri ai nonni e alla nonne che sostengono le famiglie dei figli che lavorano a tempo pieno.
Auguri ai nostri politici, che forse non lo sono più, ma Auguri lo stesso: che trovino una illuminazione e un modo migliore di condurre questo paese magari pensando meno ai loro interessi o quello del loro leader.
Auguri alle generazioni future, ai genitori che li crescono e che cercano di dargli un'educazione ed una direzione di vita.
Auguri ai carcerati, a chi cerca di redimersi e a chi non lo sa fare, e perché le carceri non siano solo un luogo di suicidi e contenzione.
Auguri a chi ha sofferto un lutto, a chi ha creato una nuova vita; gioia e sofferenza sono distanti un sottile filo.
Auguri agli immigrati ed agli extra-comunitari, che non sono diversi dai nostri nonni o bisnonni che sono emigrati con la valigia di cartone in Argentina, Canada e Stati Uniti d'America.
Auguri a coloro che si amano, a chi cerca un compagno ed una compagna e a chi non si è mai trovato.
Ed un pò di Auguri a me, che male non mi fa

Pierfranco

Why modelling when you can draw on a white board

2010-10-01T09:30:00.000+02:00

I came across this pretty fancy blogger that states that it's better do draw on a white boards "A "plain old whiteboard (POW)" is my favorite modeling tool". It then says that since these might useful to others they can be captured in a picture "We took the photo because we were afraid that we’d lose the valuable information that it contains". It's so valuable that it deserves a picture but not enought to be modeller in a tool.
Finally he shows that in order to clean the picture from the nasty reflection he used a painting program to manually remove the spot.
Another guy in a forum states "...but I use white boards. Keep many of them around so that they don't have to be erased".

No comment here. Let's say what will the future tell us.

Painting processes

2010-09-17T01:59:00.001+02:00

While digging the Internet I went through a blog with a discussion about Compensations in BPMN. This is a clear description of what I consider an anti-pattern in modelling. These persons are disguising if the given example is corrent for modelling compensation in credit card processing. There are replies in the thread that propose alternative models and explain with plenty of details why a model is wrong and why another one is correct. It's mentioned for example that there is not an undo, that the logic is wrong because one entity is reached after another.
The tebate is interesting at first, except that it lacks a key concept: the model has never been exectuted actually! Essentially in the blog people argue the correctness using hipotesys but no one has ever had the idea of executing it, "let gives some input and see how it behaves". As we have done for decades with code that implements algoriths like binary seach, bubble sost, linked list, we'd execute it in order to test it, and to find which inputs break the algorithm and then we can try to fix it and propose alternatives.
This is a nice demonstration IMO that modelling is still treated essentially like painting boxes and lines in a canvas. But hey, BPMN is a computable specification with well defined behaviours, we might be able now execute it in Intalio, JBoss, BizAgi for example like any other code. If it behaves has planned that it's correct, othervise not.
After all, a model is a code and a code is a model, we shall treat it in the same way.

Business Execution Environment, BEE

2010-08-16T16:22:00.006+02:00

IT is assuming the role of an enabler of the business. Without IT it's not possible not only to run a business, even if not related to the Internet or eCommerce; let's think in the Energy, the Utility sectors, Post, Government... This is not just because data is stored and retrieved or because there's a web site giving information, it's because the entire strategy and planning and governance is modelled and executed in the IT systems: pricing and forecast are implemented in applications, but we still miss the concept that IT "is" the business, and most of us thinks of IT in the same old fashion, or with little improvements.
I strongly believe that it's unfair to keep saying "aligning IT with the business"; this gives the false perception that business is and will run faster than IT, that a decoupling is essentially unavoidable, as it were a customer-supplier relationship. What I perceive as a message with this stereotyped sentence is that the IT has just to support the business at a faster pace. This is seen in the so now fancy "agile approach" in software development, the effect is that we give the false idea that it's all about "faster developmnent" or "faster features release". The focus in not in development but rather in maintenance, we must be aware that an application is never finished, it's continuously evolving, there is not a final deployment; the very famous RUP diagram with the phases' efforts depicted as curves, should never ends. There is no distinction between development and maintenance.
There shall be an IT environment able to host and run the entire governance of an organization, with multi level configuration capabilities in oder to allow non IT people to affect the business, to change it's strategies via an update in a business models, pricing schema. boundary values, rules. Another layer shall be able to assemble new business processes without actual development but rather using predefined services and data models. The organization shall govern on top of a Business Execution Environment, the business is in the IT and the IT hosts it, there is no gap at all because nowaday there is less and less way to influence the business without moving bits and bytes in a wire. I've seen organization struggling with post-it or spreadsheets attached via email to implement the business in a way the IT was not able yet to support. The complexity in the business and the speed at which this happen is increasing at a rate where almost no one can conceive the impacts in doing a manual change.
We shall consider the idea of a Business Execution Environment (BBE) where the business is governed and managed. This requires proper Architectural strategies and modelling techniques beause IT is still plenty of the same old multidimensional issues such as: data storage, interoperability, legacy apps, middleware, data types, technical compatibility issues, transactions, programming languages, execution platform, tools, performance, security, ids, standardization and people of course ;)

To be smart: that's it?

2010-06-12T21:53:00.003+02:00

I've attended a speech of Ivar Jacobson for the first time. He was at the Innovate 2010, an event organized by IBM on the theme of the Ration product suite. The title of the speech was "Filling the gap from IT and the Business". The title was really facinating for me since I'm struggling with this issue since a while. I was interested also because the usual phrase "aligning IT" was not used, and for sure it was done on purpose.

The destruens part was routed about the fact that IT and Business shall not play the role of customer-supplied, the entire 60 minutes was spent by Jacobson in stating that to reduce the gap it's essentuali to:

be smart
apply practises
involve the business

Is it all that? I was really disappointed of this low value statement about IT and Business. It's really underestimating the difficulty of addressing this problem. With smart people and with best of breed practises it's easy to address any problem, even out of IT. It's like saying that in order to do good builtings it's essential to have a smart project, apply good building practises and involve the client. I was expecting more from the professor who invented the Use Cases. In addition he was repeating rather frequently, with false modesty, that he invented the Use Case and he did not realize how much this'd have spread the IT and influence the way me do software.

Ivar has it's own company now, and this was pointed out pretty clearly during the speech. It's was crear that he was selling himself and this compamy of smart people with good practises. My partecipation at the speech had no return of investment.
But the devil is in the details. Is it enought to be smart, act smart and applies the best practises? But we need to ask ourself what those best practises are and how to recognize smartness? Often smart people are recognized by the result they provide and this does not assume there is a underlyng method, in IT we have to identify the patter for repeatibility. In addition people comes and go, and a team change. There is the need to factor out those aspects whatever they are, identify the method, abstract the recurring features and create values from them in order to be able to repeat them.

It is almost useless to act smart if it takes decades so reach this ability: there is too mucht time to wait and the cost of these professionals would be very expensive, as probably the people working in the Ivar jacobson Company are.

Business and IT alignment, how to escape from the sand-trap

2010-04-08T16:09:00.002+02:00

The need for the IT to be fast enough to supply Business demand, is a false problem and can even probably be dangerous, leading to disastrous solutions. Often this race creates more and more inertia to IT itself that will be less and less capable of keeping pace with the Business. In addition an IT innovationa boost the business leaving IT even more in the dust, it's a vicious cycle. The approach to be fulfill is to make the Business "ride" the IT and create a virtuous circle. There are risks in insisting with the cool idea of Business-IT alignment, the way to go is to leverage a Model Driven Arcihtecture and successfully have the Business to "ride" IT. This can be obtained with discipline, applying Actionable Architectures in the organization leveraging EA, BPM and SOA essentially, not forgetting about application architectures.
The classical style development-deployment is to be replaced by a "modelling-time" approach leaving code to only enabling infrastructure and platforms: hard-coding functionalities is evil, modelling and the separation of concerns, as conceive by MDA, is the way to go to have the IT.
The end point of the road-map is a Business Control Room where the business is measured and affected by IT actions.

business ecosystems

2010-03-23T10:49:00.002+01:00

The Service Oriented Architecture (SOA) for addressing the Business to Business (B2B) requirement is underestimating the impact of enforcing a unique functional models. It is not realistic to force business partners, and especially competitors, to comply to a unique data schema or service model. In B2B the standards cannot be enforced, not even if defined by a commission or by a standards body. There are complex mechanisms that allow standards to emerge and become de-facto, and that motivate IT and business communities to adopt them.
Also, having the support of industrial “titans” helps in the adoption process. As a general consideration, it is relevant to note that often “good” standards are not necessarily in a better position to emerge.
It is expected that reference functional models will emerge in a natural way, under the same laws that regulate standards adoption, but at a faster pace. What is expected is to replicate in a digital environment the natural selection process.

Webinar: Business Agility with BizAgi

2010-03-12T09:15:00.002+01:00

Webinar: Business Agility with BizAgi

12th of March, Soluta.Net organizes a free live Webinar: in Business Agility with BizAgi.
Everyday Organizations have a new challenge with customers and market requirements, which are in continuous evolution. Today, winner Companies are those which are able to change quickly and effectively their business processes and are looking to a new way to improve productivity.
In this webinar, Soluta.Net will show how it is possible to tackle this challenge using the BizAgi BPM Suite to automate business processes.
We will see how to automatically generate a web application, starting from a business process model, without any programming knowledge.
We will also see how it is possible to handle the entire software life cycle using the BizAgi BPMN Suite, with focus on modelling, automation, execution and process optimization.

Actionable models

2009-12-03T15:03:00.004+01:00

Because wording is important: it is the way to communicate a clear message. I have found to be useful to use the wording “computable models” to communicate those kind of precise models that can be used to drive software generation, that can be processed in order for example to be transformed, stored, searched. The message to drive is that there are type of models that are semantically rich.
A weak model is one that has been drawn with MSPaint or Powerpoint, even if drawn with a correct notation it's value is very limited because a software program can not 'decode' it, can not extract the semantics, its value is clear (and even partially) from a human being.
This is the effect I'm trying to deliver with the wording “computable model”. But I realize that this is not enough, a model drawn with PowerPoint is also computable because it can be transformed in pdf or in Open Office Impress, a more useful way to drive the message can be “actionable model”.
In this way we deliver a more efficient message, a model can be target of an action or drive actions, can perform something.

This goes beyond the property of being 'simply' computable: it's not a picture of button in a console, in a button that can be operated to deliver an action or perform a function.

Correlated Architectures

2009-10-20T16:50:00.003+02:00

Enterprise Architecture are about visibility of information, including the processes, services, resources, data descriptions and rules and policies of government. They also describe government, how it works, its resources and services
These architectures, as an information, is often captured in different kinds of viewpoints, and most of the time as models.
Good Architectures make all the data more valuable by describing how they co-relate with other organization dimensions.
The most valuable architectures are models with a formal meta model or schema, e.g. TOGAF among others.
But currently – most models are not web data accessible, they are trapped in tools, files and worst then even images as pictures and theese odels are not linkable or linked across other models. There can be models for business processes, it portfolio management, organization structures, strategies and intents, data schemas, balance scorecards, soa interfaces...
Architecture models are just data, and as such they shall be federated, analysed, queried, linked and mashed up – data to be published.
As for information they can be unconnected, redundant and not usable outside their source.
There is the need to design and develop various tools, approaches and techniques for querying, viewing, federating and analysing the architectures of the organization as a whole, this can enable consistent visibility and collaboration, provide for external comments and input from stakeholders
Last but not least, having computable architectures, we can pretend to drive and affect the organizaitons from them, making it live, more then aligned with the business, they are the nervous system of the organization.

Spaghetti Modelling

2009-10-07T09:24:00.002+02:00

The modelling based architectures, like MDA, MDE, MDD, enforce essentially a strong separation of concerns bewteen the business architecture and the technical architecture. By simply having models for defining the processes, the rules and the functional specification in general separated from the technicalities such as service binding, design pattern, deployment, state management ... is a great strategy to improve reuse, scalability, division of work across team, software life cycle, asset creation and so forth.
In essence, the application can be defined as a set of models; for example business processes, business entities class model, interfaces, UIs, business rules, component models, ... but this is not sufficient for a clear and neat model structure. The risk in ending with Spaghetti Modelling is still here; we will not end up with a comprehansible set of models of the application just because we are adopting a model driven approach.
Care must be taken in creating a proper model set that is comprehensible and that does not mix the various logical views. This risk can be reduced by adopting an application metamodel (call it application template if you wish) but it's not sufficient, in general there is the need for a good modelling practise that comes of course from the experience but also from the the good old motto "think before modelling" (aka "think before coding").
We will less an less write lines of programming language in the future (that is already here) but we will always abstract the problem space into a solution space, that is the same class of problem.

SQL NO, NoSQL

2009-10-07T09:02:00.005+02:00

Yesss, finally a movement for SQL alternative for data persistence and retrieval! There 'can be' something better.
Why lumping SQL relational statements for searching data that are natively object oriented?
Why tables, inner-outer join, stored procedures, custering of relational tables? Data is to be managed in a language and approch in line with the way we manage them in memory.
Yes, we can do better then SQL and these guys have strategies, ideas and tools!
The issue is far too complex to be addressed by a Blog here, but the problem is real and new way to deal with data persistence and retrieval is here especially now with "cloud computing" and the need to manage Tera and Peta bytes. There is more then quey language and ORM (Object Relationak Mappings), RDBMS demostrate not to be able to scale, simply because the cost is exponential and the ability to spend in RDBMS clusters is not infinite.

Ingegnerizzare il software, una chimera?

2009-08-18T14:34:00.003+02:00

Molti, quasi tutti direi, si ispirano ai processi ed a i metodi dell'ingegneria civile per strutturare e gestire il ciclo di vita di un progetto software: i metodi detti "ingegneristici" sono visti come un faro a cui tendere ed inquadrare finalmente in un'ottica di metodo e qualità lo sviluppo del software. Secondo me è una chimera e pure un rischio perché non si è capito che le due cose come fondamentalmente diverse ed incompatibili; non si può progettare e realizzare un software con i metodi con cui si progetta e realizza un punte. Perché? Seguiamo un ragionamento.
Nell'ingegnerie civile il costo di spostare un pilastro é un'ordine di magnitudine superiore al costo di costruirlo. Da millenni l'uomo prima di costruire una struttura o un edificio lo ha prima accuratemente progettato, dalle piramidi, ai ponti romani a San Pietro a Roma. L'istinto che abbiamo con questo tipo di costruzioni è: prima progetto e poi costruisco. Se dobbiamo costruire un'artefatto anche piccolo come un tavolo o una cassapanca prima di tutto facciamo un piano, un disegno, uno schema se non pure un prototipo, prima della sua costruzione. Perchè sappiamo ed abbiamo l'istinto che modificare in corso d'opera è estremamente costoso, buttiamo via materiale e tempo, c'è poca probabilità di riusare quello che è già stato fatto. In informatica abbiamo una anomalia particolarissima: il costo di modificare un artefatto software è una frazione del costo di realizzalo. Tutti noi all'inizio delle nostre esperienze informatiche abbiamo vissuto l'esperienza di realizzare subito e modificare dopo, perché "si fa prima", perché "tanto modifico dopo". L'istinto è di tutt'altra natura. Ho visto aziende mature e di successo con la stessa mentalità, partire a sviluppare senza piano o progetto o disegno perché tanto, si pensa, a modificare ci penso sopo. Questa è una anomalia in cui molti ci cascano, e debbo dire che pure li capisco. Una variabile si valorizza al volo, un software si duplica, si reinstalla, il valore di una tabella si cambia in un attimo. L'istinto di modellare, progettare, disegnare prima ed un anticipo non c'è ed il motivo è quello: modificare costa meno che fare. Poi aggiungiamo la fretta e l'agitazione di fare presto che permea l'informatico, allora abbiamo un bel quadro completo: ho visto "analisti" in piedi dietro un programmatore a dirgli cosa fare!

I processi di ingegneria hanno milleni di esperienza e si sono adattati al fatto che i requisiti di un ponte o di un edificio sono statici come la struttura che deve essere relalizzata, c'è molto poco spazio per gestire i cambiamenti. Spesso se i requisiti cambiamo, un ponte non basta più. si butta giù e si rifà. Ad un ingegnere civile non si chiede di allungare un ponte, o di spostarlo o tanto meno di costruire un altro piano mentre sotto il traffico scorre ancora. In informatica non ci meravigliamo di queste richieste, sono una conseguenza della natura effimera (soft) appunto di questa strana scienza (oddio..scienza, ho esagerato, l'informarica pare più essere un'opinione).

Consideriamo per un attimo anche gli strumenti di sviluppo. Per fare una casa servono degli strumenti costosi e complessi come delle gru, scavatrici e betoniere solo per dirne alcuni. Nessuno di noi pensa che per farsi una casa in un terreno che abbiamo basta fare un corso di "gru" o di "scavatrice". Sappiamo che lo strumento non basta, non serve neppure essere un bravo operatore. Ci sono processi, altri strumenti, tecnologia, scienza, progetti. Questi strumenti sono innanzi tutto costosi da ottenere, voluminosi ed una volta ottenuti non siamo in grado di usarli. Il nostro istinto è di andare dai professionisti! Il nostro istinti è quello di andare da un geometra o da un architetto che poi invocano un ingegnere per la fattibilità che poi chiama un'impresa edile: ogni uno
sa cosa fare ed ha un ruolo ben specifico.

Ah, ma in informatica i tool si possono scaricare da Internet, e sono spesso free a partire dai data base, agli IDE, UML editor, application server, GUI framework, linguaggi, VM, middleware ... tutto freee, tutto scaricabile. E tutti ci sentiamo in grado di metterci ad usarli, tutti credono e hanno il diabolico istinto di poter creare di poter realizzare un software solo perché hanno gli strumenti a portata di un click! Vedo nelle librerie libri contitoli come "XML in 24 ore", "Impare EJB in 2 giorni","Diventa un webmaster", e li vediamo e magari ci facciamo pure il pensierino di prenderli che qualcosa magari insegnano pure. Fate un salto nella sezione "Medicina" e cercate "Diventa un chirurgo del cervello in 24 ore", "Fai fa te: il trapianto di fegato in 24 ore", "Chirurgia vascolare in 48 ore". Se vi fa ridere allora dovete trovare il modo ri ridere anche per quei titoli informatici. Assurdamente ritengo che se i tool pesassero 10kg a Megabyte, se occupassero 1m^3 a Mbyte avremmo meno problemi: dove li mettiamo? Questa manna di tool free e potenti a disposizione non hanno bene all'informatica secondo me, avremmo contrastato questa mania di onnipotenza, poter realizzare qualunque cosa solo perché abbiamo accesso agli strumenti. Pensate a quanti disastri avremmo fatto se possedere una ruspa o una scavartrice fosse facile e economico come comprare una levigatrice.

Mettiamo assieme le due cose:

costa meno modificare che fare
gli strumenti sono accessibili a tutti
e vediamo che viene rivoluzionata una buona fetta di quegli elementi propri dell'ingegnerie civile, quello che resta è il knowhow ed i processi che finiscono sottostimati e sono la causa principale del fallimento dei progetti IT.

Comunque, non mi si fraintenda: in informatica quando si realizza del software c'è ovviamente bisogno di progettare e molto! Serve "pensare" a priori prima di scrivere un "main", ma non per gestire la complessità della realizzazione del prodotto software, non per la sua realizzazione ma per ottenerne la scalabilità e la manutenibilità, per poterlo gestire nel suo ciclo di vita. Il software è quasi un essere biologico, non è immutabile. Sono aspetti che nell'ingegneria civile non sono gestiti. E' un aspetto non intuitivo che il cliente innanzi tutto non chiede per primo (lo vuole dopo, assume "dopo" che avrebbe potuto scalare sulla tecnologia 'x' a costi '0'), ma lo vede solamente l'informatico, l'architetto che può dire "ne ho viste di cose che voi umani non potete nemmeno immaginari", ho visto progetti perfetti fallire per non aver gestito un requisito, per non aver saputo scalare il numero di utenti, per non essere stati in grado di supportate l'estensione delle funzionalità, per essere stato in grado di supportare una diversa piattaforma...pare che siamo anche incapaci di imparare.

Del famoso Tacoma bridge, non metto neppure un URL qui, trovatevelo è un caso famosissimo, è stato studiato a fondo per evitare che si ripetano tali errori: in informatica pare non si faccia lo stesso, un'analisi post mortem di un progetto è sempre da assegnare ad un “capro espiatorio”, spesso erroneamente alla tecnologia “X”, pare che in informatica non si possa imparare dagli errori.

Alla via così.

Architetture IT e di Enterprise stanno per congiungersi

2009-08-14T20:53:00.004+02:00

Le architetture di enterprise hanno un ruolo importante nelle aziende di grandi dimensioni in cui ci sia la necessitò di definire sia I processi IT che quelli di business con lo scopo principale di allineare il business all'IT. In questo contesto sono state definiti diversi metemodelli come TOGAF, MoDAF, DODAF, ITIC, COBIT, BMM per non citare il classico Zachman.

Diverse imprese in Italia ne hanno adottato anche più di uno e il trend è di allungare questi approcci alle architetture IT per ottenere un vantaggio di scala attraverso la generazione di codice o di infrastrutture; si tratta in questi casi di tecniche orientate ai modelli come Model Driven Architeture (MDA), Model Driven Engineering (MDE), Model Driven Development (MDD). Ad ogni modo, indipendentemente dall'acronimo o del consorzio che è stato sposato si assiste ad un corto-circuito tra un cammino bottom-up, guidato dalle esigenze della software factory che intende armonizzare I suoi processi, raccogliere e gestire I requisiti e generare parte del codice di piattaforma con uno top-down voluto dal gruppi di Enterprise Architecture per la governance dell'impresa.

L'obiettivo è che le due piramidi si tocchino al vertice in modo armonico: il fine che permetterebbe di vedere finalmente l'IT come sistema nervoso del Business e non come “il centro meccanografico”.

Where is MDA going to? My personal wish.

2006-10-29T18:35:00.001+01:00

Many days ago I published a post about an MDA article , it was about Elaborationist and Translationist approach, and about a “hole” between them. Here it is my personal wish:

1) I'd like to have a computationally complete UML subset for the MDA context;

2) I'd like this subset to be as much general as possible;
3) I'd like to execute and test the models directly.

Having a computationally complete UML subset means that every model has its own semantic, and every model can be an actual part of a system. To define the best syntax for action semantic there is no need to chose between Object Constraint Language and Action Language, the right solution would be to have a mix of the two, defining a resulting language that inherits the best from both the declarative and the imperative approach. I wouldn't like specialised UML diagrams for the embedded systems and other diagrams for the business systems, the models should be domain independent. Does exist a good reason to define specialised UML diagrams with specialised semantic? Domain Specific Languages should be introduced only when really necessary.
I'd like to have the most general models, to exploit abstraction, to keep domain and platform details as near as possible to the end of the model transformation chain.
And finally, I'd like to execute and test models directly, is a key feature for an MDA tool, I don't like to write models and debug Java, C or wathever it was, “I think and write models, and I want to execute and debug modes!”.

The PRC UML set of models

2006-10-15T12:31:00.001+02:00

Suppose we have a subset of UML for which a completely defined computational semantic exists. So, for such a set, could even exists a Virtual Machine that would able to simulate, debug and execute every model formalised in that UML's subset. Let's call this subset cUML, like “computable” UML and the corresponding Virtual Machine the cVM. That would be a great point to start from, because we might be able to construct every system that could be modelled with cUML, as an actual executable model in the cVM, in the the best spirit of MDA that fosters system construction by models and model transformations.

The problem now might be how to execute in the VM a model that is a UML model, but not a completely cUML model – i.e. a model that contains some elements that are not representable in cUML.

But always in the MDA's realm we could design and implement a transformation, from a UML model into a cUML model. Suppose for instance, that we have a BPML model, say M, that is contained in UML, but not contained in cUML. We could than write a transformation from M to M', where M' has exactly the same behaviour as M, but M' completely belongs to cUML. That could be a transformation from UML's metamodel to cUML's metamodel (and cUML's metamodel is still a subset of UML's metamodel). In that case we would be able to execute M' – and thus M – in the cVM !

What does this mean? In my opinion this means that we could have a great tool to execute a very large set of models, I would call this set the PRC UML set, where PRC stands for Primitively Recursive Closed. This is not a very new idea, it is the same idea used in the theory of computation where the PRC sets are basilar. The PRC UML set is composed by all that models that can be written in terms of cUML's elements, models constructed by composition and recursion of cUML models. That would be a great tool in our hands.

To be more practical I would say that

If you have a cVM, and you are facing for instance a problem that could be modelled as BPML, don't stop you from executing it, find a transformation – maybe a manual transformation as a first approach – to obtain an equivalent cUML model, and execute it! For instance, if in cUML we have class diagrams, state diagrams and action language to model behaviour, than we can transform an activity diagram, a sequence diagram or maybe a BPML diagram into cUML. It's not impossible and it's not absolutely wrong. Having a non executable model is not a good reason to stop from executing it, al least in many practical cases.
One fine day, someone could formalise and produce an automatic transformation from UML to cUML, in that case we all would have a way to execute high level UML models into a cVM. In other words we don't have to wait for a completely formalised computational semantic for UML – a Titan's job (*) – we could do that kind of magic with only a small cVM and a bunch of good transformations !

(*) I didn't use *Titanic*, for obvious reasons :-)

UML completeness and complexity

2006-10-07T22:27:00.001+02:00

So often I've heard IT people talking about their difficulty in using UML. The reason for this spread “feeling” maybe lays the fact the UML is now a very large set of conceptual tools, and it is still growing. Personally I understand and appreciate the great value of the work OMG's people is doing to complete UML, toward an actual Unified set of modelling elements; I think the community needs such formalised concepts. Nevertheless I see that for a lot of people is very difficult to approach analysis and design with UML: which diagram is more appropriate, from which point of view should this matter be modelled, which is the exact meaning of this set of elements, are all questions that can reduce the confidence in UML. I believe – and this is an opinion not a matter of fact – that a meaningful reduced set of UML could be a more aggressive proposal to push on UML in the IT community. What I'm thinking about is a subset of the whole UML from which would be possible to obtain the models we need, less diagrams but well known, widely used and completely understood. Finally, we could aim at very valuable objective, a completely computable UML. Currently many efforts are carried on to define specialised subsets of UML to fit the needs of particular fields of application, but this is not what I'm thinking about, I'd like to have a pervasive Unified Modelling Language and not many specialised Disjoint Modelling Languages.

At last, I know which is my job

2006-10-06T21:59:00.001+02:00

Has always been a problem to explain to many people which was my job. Usually I was the “guy that works with the computers”... Yes, like the writers work with books, and the musicians work with guitars. Now things are changed, I know that when I write a piece of code I'm modelling an algorithm, I'm using the model suggested by the programming language, and when I test a program I'm executing instances of a model. To think about software engineering processes is thinking about models of activities and interactions; a software architecture is a model that drives the analysis and the implementation of an IT system. Software components and their interfaces are models. And finally, we have MDA that promotes the specification of IT systems as a sequence of related models.Unified Modelling Language!... Wonderful. Thanks MDA, thanks OMG and many thanks to all my colleagues. Now I know which is my job: “I think about Models!”.
“Uhm, interesting, you mean ... Top Models?”.

Which model for UI in the MDA?

2006-10-05T21:13:00.001+02:00

User Interface (UI) is often an important part of an IT system, and MDA suggests to describe such a system as a set of related models. Finally, in our actual projects we'd like to follow an MDA process and to use MDA tools that could produce the executable code from models. In this scenario the UI is a domain of the whole system that requires to be modelled, with the ultimate goal of integrate it and generate it with all the other necessary application domains. I think that UML could be a good tool in describing some UI characteristics, for instance it might be possible to capture some common properties of the UI components: the displayable and editable class attributes, the navigation, the relation between class of forms, the common attributes of the UI components such as the “OK” action handler, the “Cancel” action handler and so on. But the responsibility of a modeller in the MDA context is to capture every application-significant aspect of a domain and, for the UI, properties like screen position, colours, dimensions, fonts, input masks, are fundamental requirements. At this point my personal idea is that UML alone it is not enough for a convenient modelling. Furthermore, we'd like to model UI in a WYSIWYG fashion. Maybe it turns out that a modelling tool, specifically designed for UI modelling, would be better: a rich application that let us draw a complete UI and produces the underlying UML. Often, formal input controls are also part of a non trivial UI, how can the tool cope with this kind of UI application logic? Are still the underlying UML and its meta model adequate? Or wouldn't be better to use a tool that generates a separate UI code module, that integrates with the other system domains with established interfaces, maybe forsaking this way the possibility of future XMI export and import?

Hierarchies: only a human artefact?

2006-09-12T17:24:00.001+02:00

Most of the solution in SOA, like the cluster of UDDI registries, are based on an hierarchical structures because this is the way humans do in order to deal with complexity, i.e. in order to create comprehensible models.

But as a matter of fact, the reality is not hierarchical at all, this is the reason why information models becomes more and more unmanageable with the increase in complexity. Below a certain degree of complexity, the model can be oversimplified and a hierarchy represent a good approximation, but when complexity increases, it becomes impossible to stick to an hierarchy because reality is not as simple and it's based on different models and topologies, for example Scale Free Networks.

The risks in understimating MDA

2006-09-07T23:14:00.001+02:00

MDA, if applied correctly, promises to change the way we deal with software development:

is it everything going to change?
Are we really going slim down classical software development methods and processes?
What shall we expect and tackle in a MDA/MDD based project?

The idea is that those problems, the same old problems are still here, and the risk is in underestimating their impact.
MDA approach need to be supported by a proper method, process and tool otherwise it'd not be possible to achieve the provisioned advantages, on the contrary the project may collapse at a faster pace then non MDA based projects.

Why do we still need username and passwords?

2006-09-07T15:15:00.000+02:00

What are passowrds for? I got cookies, PKI, signatures . A password is of the old time, IT need to get rid of it.

The impact of UML documentation on software maintenance

2006-09-02T19:16:00.001+02:00

There is an interesting article on IEEE transaction on Software engineering volume 32 June 2006 about "The impact of UML documentation on software maintenance".

The conclusions of two experiments are mostly consistent.

No savings in effort are visible.

the conclusion of the article are:
This pare presents the results of two consecutive experiemnts which have taken place in two different locations. The goal was to shed some light on the cost effectiveness of model-driven development with UML. because this is a very large area of ivestigaiton, we focused on whether models help software engineers to make quicker and better changes to existing systems. It is very ocmmon in practice to have software engineers making changes to systems they have not developed and maintenance consumes a large portion of the resources in typical software organisations . This why we thouht that this was an important first question to investigate , though we realize that model-driven development can be useful in many others ways(e.g. code generation). The result of our two expriments are mostly consistent. When considering only the time required to make code changes , using UML documentation does help to save effort overall. On the other hand, when including the time necessary to modify the diagrams, no savings in effort are visible. However, in term of the functional correctness of the changes, both experiments seem to indicate using UML has a significant , positive impact on the most complex tasks.

In my opinion this result reflects two importants points
1) the tools for approaching MDA are not mature , they can improve in usabilty
2) the skills for working with MDA with effectiveness are very high

what we need to lower the cost are probably some tools MDA that simplify the use of some subset of UML, so we can use "normal" people.

what you think?

Where is MDA going to?

2006-08-31T18:35:00.001+02:00

Recently, while digging into the Internet searching illuminating words about MDA, I found an interesting article written by Ashley McNeile. The author presents very clearly the opposition of two mainstreams in developing MDA tools, the Elaborationist and Translationist approaches. Recently, during the last year, I've been involved in two different MDA projects, the first was actually an Elaborationist one, and the latter absolutely a Translationalist MDA project. I have a steady personal idea about the two approaches, quite a clear envision, supported also by these two recent personal experiences.
Is really so difficult for the opposite methodologies to converge into a comprehensive one?
I've my personal opinion about it, stay in touch, I'll write out more in the future...

Software engineering: and oximoron (and it will be forever)

2006-08-31T11:47:00.001+02:00

The civil engineering principles and practises start from the obvious real fact that "it costs more (much more) to change than to create" and this undoubtable fact is reflected and it influences the entire approch.
In IT, on the other hand, the undoubtable fact is that it costs less (much less) to change than to create (at least in the short term in the life cycle of projects) and this has badly influenced the IT practises until the early time when complexity and urgency became a preminent factor.

But now we are not yet able to get rid of the Software Engineering principle in IT! We still look at it as the leading light, the guiding principles. But this is badly influencing the practise, approach and methods of IT. The early 90s heavvy methods are still here with us even thought something is moving in the right direction: MDA.
The software developement processe need to leverage its own advantages which is flexibility and adaptability instead of flighting it. The fact that is cheaper to change than to build is a value added, unque to IT because of its inner "soft" soul, it's not a deficiency to fight.
Beside the fact that in IT no one can affort to wait one or two years before having a usable software product (which is common for planning, builiding and using a bridge or a skyscraper). Let's assume that in IT we first build and then we change: it's in the human nature. In engineering practise, we first want to plan and then to build because we can not economically and practically afford to move a house or to move a window. This approach has emerged naturally more then 2000 years ago, IT is not as lucky: it is just 50 years old and we are probably now understanting how to deal with it.

Software artifacts are far more adaptable then any other hardware or concreate stuff. Let's then create an approach, process and supporting tools that not only accept this fact but also use it at the value add, the leading principle. In essence MDA is exactly doing this: creating an approach founded on "flexibility" that accepts, admits and wants IT system to be build by continuous changes. Yes it sounds like the Iterative & Incremental approach, but not as a cure to the heavvy engineering approach of IT, but as a prime strategy. In essence MDA wants to even ease and support the fact that it is cheaper to change than to build and put it as a "method".

We have to dare, and to get rid of the past approaches and go in another direction supporting a characteristic that was considered the "devil", it is in reality a good think if wrapped around a formal approach that OMG is actually defing and formalizing.

On the other hand, we shall not fall in the error of considering that MDA is "do & try", "do & fix" or "plan afterward" on the contrary: changes need to be planned. MDA, making a comparison with civil engineering, is building a development method (development here is used in a broader sense) around the uncontrovertible fact that the cost of moving a pillar is far less expensive then the cost of building it! Would we have the actual Eng. methods in civil construction, for example, if adding a story to a building would be as cheap as building it since tbe begining? Not indeed, then we have to assume the same in IT, and start all over again with a different new mindset: a tabula rasa.

MDA TOOLS using MICROSOFT LIVE WRITER

2006-08-28T21:11:00.000+02:00

This page gives an overview of some MDA-oriented tools, some of which are pure code generation tools, others more full fletched model-driven tools. They may all be part of someones MDA (™)process. Of course, UML tools may also be considered MDA tools, and will often be central in model-driven development. If that is what you look for, see the UML tools link.

Below are some open source tools of different character:

MOFScript , a model to text transformation tool, based on one of the OMG MOF Model to Text Transformation submissions - Eclipse plugin, based on metamodels/models in EMF.
The IBM Model Transformation Framework (MTF) is an EMF based model transformation framework , for now available at alphaWorks. It provides a declarative means of specifying metamodel relationships, similar to that of QVT relations.
The ATL Engine is a QVT-based transformation language, developed by the INRIA Atlas team. The ATL Engine is currently available as open source under Eclipse GMT. It is developed as a set of Eclipse plugins and works as a development IDE for transformations, with execution and debugging. Currently integrates with EMF and MDR. The ATL Engine will be developed further within the ModelWare IP.
MTL Engine - Another QVT-like implementation, by the INRIA Triskell team. Uses the MTL language. Integrates with Netbeans MDR and Eclipse EMF.
ModFact A MOF Repository and QVT-like engine from LIP6, Paris. Based on the TRL language. LIP6 are also working on an open source ModelBus implementation, which will enable MDD tools interoperability.
Generative Model Transformer (GMT), an eclipse project that is providing/will provide model transformation technology for the eclipse platform. Currently the FUUT-je tool, a code generator tool, is the primary GMT deliverable. (ATL, mentioned above, provides core transformation technology....)
Kent Modelling Framework (KMF), a tool for generation of languages with support for dynamic constraint checking.
OpenArchitectureWare , a flexible, template-based generator framework integrated with XMI.
OpenMDX, an open source MDA environment, which integrates with several tools through XMI and supports code generation towards several target platforms (J2EE, .Net).
AndroMDA, an open source template-based tool for J2EE code generation from UML/XMI. Uses VTL (Velocity Template Engine) as scripting language and Netbeans MDR as a model API.
XDoclet, an open source, attribute based code generation tool for J2EE. Not really model-based, but can be combined with generation tools such as UMT to achieve good model-based value.
Middlegen, an open source, database driven code generator based on JSBC, Velocity, Xdoclet and Ant.

MDD/MDA and the role of the Development Process

2006-08-28T16:42:00.001+02:00

MDD tends often to underestimate the impact of the software factory: in details, the role of the process. The organization of work and the hierarchy changes, it is not the usual software engineering process with Analysis-design-code-test, but a rather different approach where test happens in either a PIM environment, where the design happens is an parallel task out of the streamlined production process.

Under-estiamating the role of the process can reduce the advantage of MDD/MDA.

The development process when working with in MDD/MDA has been devided between different groups, testing and technology mapping have to be considered.

MDD can push the development process at a speed where the planning is postponed and will create obstacle and difficoulties in further phases of the project like it happended with 4GL. Planning as well as an accurate requirement capture and a proper analisys modeling greatlny contribute to the success of and MDD based development process.

Embracing the usual software engineeting process when applying MDD is overlookin the problem and increases the risk of the project.

Obeo MDA Tool by Acceleo

2006-08-28T01:25:00.001+02:00

Obeo has released an MDA Open Source tool, Acceleo.
It interesting to notice that more and more MDA tools are available out there which also support UML2, QVT, MOF and are based on the Eclipse framework.
Last but not least this is FL/OSS