So, are Cloudfier applications models or programs?
Long story short: both. But read on for the scoop.
(Note that this is the second installment of the Cloudfier series started in this previous post)
Programs vs. Models
We write programs to tell computers to do things, and we create models to communicate ideas to others. Cloudfier applications are executable models. Executable models are amazing because they allow us do to both things at the same time: they are complete and precise enough to be considered programs, yet they allow expressing intent and communicating ideas well. You can say that executable models are programs optimized for communicating intent. And this turns into a nice set of side-effect benefits.
Technology independence
One very interesting side effect of that is that when you limit yourself to communicating intent, you naturally end up leaning towards technology independence. So as a consequence of being designed for communicating intent, executable models are also programs that are technology independent, and hence they are future proof. When what is considered the best technology for building software keeps changing every six months or so, that is a big win.
Concerns become separated by nature
Executable models allow separating the solutions to business requirements (dealt with by the executable model) from the solutions to non-functional requirements (which are dealt with via code generation or model interpretation). This separation of concerns by nature has two nice consequences:
The problem domain gets the importance it deserves. Ever tried to understand the business requirements of an application by inspecting its code base? It is really hard – and the reason is that solutions for business requirements have to be encoded with the mechanisms provided by the implementation technologies. Not only they often favor the need to communicate with the computer (frameworks, APIs etc) over communicating to others, but tend to mix solutions to a plethora of non-functional requirements with the basic solution for the requirements from the problem domain, which ends up obfuscating the latter. And in case you are wondering, it is the solutions to the business requirements that really represent the value of a system.
The architecture can be evolved in a cost-effective way. At the same rate, ever tried to upgrade the architecture of an application of any decent size? Sometimes, even moving to the latest version of a framework is so hard (or at labor intensive) that it is usually not done, and the application goes slowly but surely down the slope of obsolescence. With executable models, since the technological choices are not encoded in the application “source code” but elsewhere (the code generator or the model interpreter), you can evolve the architecture of the application without having to revisit how you addressed the problem domain requirements. You can do small adjustments to the architecture as you go very easily, but you can even completely change the target programming language (or support an additional one).
Executable models promote an approach that deals with business and technology as separate dimensions
Opportunities with Executable models
Developing using executable models in general (and hence in Cloudfier) opens up some very interesting opportunities:
- You can express the conceptual solution for the business requirements using constructs that provide the proper level of abstraction, such as relationships, constraints, state machines.
- You can let business stakeholders play with and validate the model not via diagrams, but by interacting with a fully functional application (running on a temporary tech stack).
- You can test your application at the model level.
- You can easily change the way you generate for a given target platform.
- You can generate the application into two or more target platforms.
- You can build your own generator, or buy/get it from a third party.
- You can sell or somehow let others use the generator you built.
I will cover these scenarios and how they are supported in Cloudfier in future posts. But if you have any questions about them now, just use the comment area below.
Founder at Abstratt Technologies, where he builds Eclipse-based tools (such as Cloudfier and the TextUML Toolkit) for model-driven development based on executable models, and consults on MDD, application modernization and software architecture. Rafael has BS/MSc degrees in Computer Science at UFSC (Brazil), and has developed software professionally for more than 15 years, in Brazil and in Canada, where he was once a committer in the Eclipse Platform Core team at the IBM/OTI Ottawa Lab.
Program specifications at an abstraction level above hexadecimal machine code are textural representation of a model with higher level semantics.
Hi Antonio, sorry if I am being obtuse, but I didn’t understand your remark, or at least to what part of the post you were commenting on.
My take is that he is saying that in fact every program is a model?
I see now. Yes, levels of abstraction are relative. But just because something is at a higher level of abstraction than another thing, that does not mean it is at a level of abstraction that is sufficiently high (3GL programs do not provide a level of abstraction that is sufficiently high).
In this post, when I am talking about programs, I am talking about programs in a mainstream programming language, in other words, in a third generation language, such as Java, C, Fortran, Ruby, Python, Smalltalk etc. At the same rate, when I am talking about models, I mean models in mainstream modeling languages, which are meant for human communication (3GL programs do not qualify here), and are not executable. Finally, the point here is that executable models allow us to achieve the benefits of mainstream modeling and programming languages without their shortcomings.
Rafael, yes I was being extremely obtuse, and Jordi put it just right.
Excluding – may be – hexa machine code – just because I know nothing of level of abstractions lower than machine code, so for me it is the rock-bottom abstraction level, for which the textual representation of the model, and a “program” have exactly the same syntax and semantics.
Tried to write a comment. Got a bit longish. So I put it here:
https://modelpractice.wordpress.com/2015/07/30/model-requirements-execution/
Regards
|=
In brief: Executable models have a great potential for achieving real separation of concerns. However, some practical modeling aspects on the business side deserve closer attention. It is the concern of understanding by the biz people vs that of precise logic for further processing towards execution.
Interesting point. Executable models, being programs, deal with the solution, not the problem statement, so they provide no mechanism for encoding requirements. They do allow one to discover requirements more easily though, since there are only the business problem domain concerns to address, and executable modeling languages such as UML provide mechanisms (such as constraints) that make business rules more evident.
My approach to making requirements stand out in executable models, just as when I am programming in a 3GL, is to write automated tests (at the model level) that encode the requirement from the point of view of the problem statement, through various success/failure scenarios. For example (copied from a Cloudfier example project):
operation finishedUponReturn();
begin
var car, customer, rental;
begin
car := Examples#newCar();
customer := Examples#newCustomer();
customer.rent(car);
end;
begin
rental := customer.currentRental;
Assert#isTrue(rental.inProgress);
customer.finishRental();
end;
begin
Assert#isTrue(not rental.inProgress);
end;
end;
The added value here is that tests are executable, so they can be used to continuously validate the solution, can be mapped to the target platform as tests in 3GL code etc. Granted, they still are not necessarily in a language that is accessible to business analysts in general, but I strongly suspect generating an accessible representation based on test cases should be doable (i.e. generate BA-oriented requirements from tests).
Also, from the end of your post:
Note (and you may have guessed from my previous reply) that the ambition here is to serve business application developers by raising the level of abstraction they deal with and getting the technology concerns out of the way. The idea here is not to enable business specialists to produce software. Even with executable models, we still depend on developers (not business analysts) to express the solution (executable models are solution-oriented models). However, developers/modelers can work at a level that is much closer and more focused on the business domain than the traditional way.
Ok, thanks, now I got it, where your scope lies.
Sorry, to confuse you with these tool vendors that promise ‘everything’ (and not able to keep it). Think, restricting your scope here, is a perfectly reasonable thing.
So, I understood the intended process like this
1. I work out my req model, say a logical ER model, with my dedicated req tools.
2. Import/ update the ER model with cloudifier as the ‘biz centric solution’
3. formalise/translate constraints
4. optional: define and run test cases in cloudifier
is that roughly it?
So long
|=
That sounds about right, but:
1. could be any sort of requirement gathering technique you like – no formal requirement models required
2. you would be creating the solution model somehow driven by the requirements: could be by hand from reading a requirements doc, or TDD-style, by recording requirements as test cases. etc
3. sounds good
4. I would not skip encoding requirements as test cases (but yes, technically optional)
plus:
5. let business experts (BAs, users) validate the solution model by playing with the automatically generated fully functional prototype
6. generate the application for the desired target platform (also technically optional, if you are using Cloudfier just for prototyping)
Cheers,
Rafael
Ah, that’s clear.
Hence, on one hand one has the usual req/dev integration issue, on the other the test/ prototyping capabilities are certainly a big plus.
Thx
|=
Some level of it, yes, but I believe that by removing tech concerns from the equation, developers can be much (maybe 10x) more responsive to addressing business domain requirements than typically.