http://www.modeldrivensoftware.net/profiles/blogs/mdd-meets-tdd-mapping-requirements-as-model-test-cases

I just went through this and go stuck as well, but with a different error:


Internal error (java.lang.IllegalArgumentException: Can't find template pojoEnumeration.st; context is [actual_pojo_enumeration]; group hierarchy is [my_tests])


but that was because I forgot to declare the template ancestor:


group my_tests : pojo_struct;


Please make sure your template starts with that. I just updated the example code for the template accordingly.

The final goal of the exercise is to produce no errors, IOW, something like this:


Model compiled successfuly in 0.147s
Code generation tested successfuly in 0.51s


So, is “No tests found for my_tests” the “correct” answer, at the end of this exercise?

Re: thread safety – one could assume thread safety is ensured by some other means (say, service level). The code generated here (the “POJO” target platform) is intentionally simple and ignores non-essential/non-functional concerns. The same thing explains the use of a static slot to keep all instances, which has no role in a real-world application.

ergo => I would NOT hire the developer who wrote it

The trivial mappings I refer to is exactly the kind of transformation model-driven tools perform. They may seem complicated to a non-technical user, but for developers that know how to do it, they are utterly boring and repetitive. Automation, by taking care of the non-intellectually challenging work, allows developers to focus on getting the domain model right, which is what matters most anyways.

Does that make sense now?

I’d disagree with III and VII, although it’s probably just a question of how you’ve expressed them.

“III – What makes a language good for implementation makes it suboptimal for modeling, and vice-versa.”

A good Domain-Specific Modeling Language is great for implementing in. Implementing just means “what you need to do to write one more application”. Of course there are generators and frameworks under the hood of a DSML, but that’s true also for languages that you’re considering ‘implementation languages’.

I wonder if a truer version would be “what makes a language good for a particular domain is what makes it suboptimal as a general purpose language, and vice versa”.

“VII – No modeling language is more understandable to end-users than a running application (or prototype).”

I’d disagree. A good model of structure, states or UI flow allows you to see the whole application at once, whereas using the application means you have to spend extra time pushing the buttons, and only see a small piece at once. That’s why we provide documentation to end users, often showing structure or flowcharts.

Clearly though the ideal is the combination of both. I’d argue that such a combination is also the best thing for the developer, so he can go quickly from adding a bit in the model to testing that in the running application.

How about simply “11 principles of MDD”, or “11 lessons learned from MDD” (if you justify them from concrete experience)?

http://www.roperia.com/article/362/analysis-and-design-vs-description-and-translation

@rafael: like you, my introduction to OO modelling was through Rumbaugh et al. At the time, the proposal that “analysis = understand problem, design = specify solution” held intuitive appeal. However I always seemed to get caught up in unfruitful debate: there was always some element that someone maintained was ‘analysis’ whilst another was equally adamant it was ‘design’.

And then I was introduced to Shlaer-Mellor. It bent my mind. It took a while for the neurons to reconfigure themselves – and unlearn several years of accepted wisdom.

But the approach brought stunning clarity to the interminable debates of “analysis vs. design”, “problem vs. solution”, “high level vs. detail” and such like. In SM you’re either modelling a problem domain (“analysis”) or defining the bridges between domains (“design”).

Precision pervades. So domain models are precise, executable, and thus amenable to highly automated translation.

In fact I’ve stopped using the terms “analysis” and “design” because they’re so loaded with baggage. Instead I use “description” (modelling) and “translation”. I’ve used those for 10 years now and find them as useful now as I did then.

For one, the example model is very simple, so it is not like it requires more features that you won’t find in ordinary programming languages. If it dealt with associations, state transitions, events, things that UML supports natively but need to be emulated in programming languages, that would be more evident.

But after all modeling and programming (in Java or assembly) are just different tones of the same gradient, so if you ignore the nuances (like the intended use cases), it is hard to see any differences between them.

what in your examples is specific to modeling and would be different when programming?

I still don’t understand the difference between modeling and programming.

Cheers,

Walter

To clarify what I mean by “problem” vs. “solution”:

Problem: a need a customer (expert in the problem domain) has and needs addressed by a new system.

Solution: a solution to a customer problem to be defined by a “developer” (expert in software).

I do see a lot of value in classifying activities on whether they help elaborate or further refine and clarify the problem statement, or whether they help address the problem with a (computer-based) solution.

S/M’s (or MBD’s, or xUML) OOA seems to blur the distinction between problem and solution by covering both (deepening problem understanding, and building a partial solution that focuses on the problem space and ignores the computing space), but I still believe that does not change the fact they are two different things.

You may be right for DSL-based modeling, but for Shlaer/Mellor, Lahman’s MBD and Executable UML, I don’t think so (and that is what triggered this post). In those approaches, understanding of the problem (as much as requirements gathering can) precedes OOA and is out of scope as a discrete activity. OOA starts right off the bat with *addressing* (solving) the customer problem – in terms of the problem space, but it is still “solution”. Deepening/refinement of the understanding of the problem happens implicitly as the OOA model is built, much like a designer (or even a developer) that is given incomplete requirements has also to further the understanding of the problem (an issue that executable modeling helps mitigate) in order to complete their work (which is solution centric).

In case of an executable modeling, there is a difference between problem analysis and conceptual solution. The result of the former is ontology models and understanding the problem – these are not executable.The former is input for DSLs and model interpreter development. The latter drives a solution model specification in the executable DSL. When another problem needs to be solved in the same domain (hence domain analysis is not needed), first the problem needs to be understood (analysis) and then a conceptual solution modeled.

I’ll specify a “alteration of thought” for starters. In case of structured-generator scenarios, the intense refactoring of generators may apply, and you don’t actually care for generating the alike output.

In case of such dynamic generation methodologies, what you care for testing is the final code that is full result of the generated code.

I’m currently in process of demonstrating software definition requirements through design level abstraction.

The funky stuff happens with performance level requirements; I am demonstrating also software-development generic building block “operation” that has parameters and result value (both optional).

Properly generated every software can be made by such blocks.

Now combined with performance level requirements, some higher-level operations are in “test build” injected with assertions that will watchdog the required performance to actual performance.

This will on the other hand also provide means for recording the actual data that goes through the operation chain.

If your architecture allows and you have decent amount of testing data (that you can simply record from “test recorder injected generated code”) or in some architectures (such as event-sourced architectures) you can simply rerun all the cases through altered generators.

This will of course rely mostly on full-chain tests (in from service layer, assertions on what goes to database), but if you get those tests for “almost free” its a good start.

Now I haven’t looked to your generation model, but I’d assume that as you’re doing heavy generating already, I assume you can do the injection alike as we can.

So sorry for dodging the question to provide alternatie solution, but in addition of testing the generations, if you can also get relatively cheap way of testing the “final application”, it supports the proving that generators work as intended.

Cheers,

Kalle Launiala

I keep the expected results in files in the project. This has two advantages:

1. Those files are usually pretty large (> 10 lines) and keeping that inline in the test code would make the source unreadable.

2. I don’t have to escape the test results making them easier to read in the “default editor”.

The main drawback is that JUnit has no notion of “compare String to file content”. My solution is a readText() method that takes a file name and optionally an encoding (UTF-8 is the default) and then, I use

expectedFile = new File( “expected/….” );
actualFile = new File( “tmp/….” );
String expected = readText( expectedFile );
String actual = readText( actualFile );

if( !expected.equals (actual) ) {
assertEquals(
expectedFile + “\n” + expected,
actualFile + “\n” + actual
);
}

This way, I have the file names in the test comparison.

All tests write their output to actualFile so I can open those in a “default editor”, too.

I haven’t yet figured out a way to automatically test with some parameters; that depends on how “suitable” your model elements are for automatic generation in tests.

To solve this for “cumbersome” model elements, I have test data factories which create me suitable complex model mocks.

I agree there is nothing about your example that would make it not suitable to be handled in the executable model, as it is clearly addressable in terms of the problem space. I often struggle with the concept of non-functional requirements, and I tend to tie them to crosscutting concerns in the computing space, and for requirements like the one you suggested, I tend to come up/look for functional requirements that would serve the same purpose (the NFR being a rationale for them).

Model compilers are available for five-figure US$ amounts from (eg) Mentor Graphics, which, compared to half-a-year’s salary is a steal.

OlivaNova has a different model. They sell translations based on a high-water mark. That is, if you generate 10000 lines of code, you pay a certain amount. If you retranslate and produce 12000, you pay for the additional 2000 lines. Subsequent generations of less than 12000 lines are free. Until you go over that high-water mark.

I have learned, through years of teaching, that the hardest task is get a student to “unlearn” certain ideas that inhibit the addition of new ideas to their tree of knowledge. For example, the title for this essay asserts that “analysis,” “problem,” and “solution” constitute some branches of the (software engineering) tree of knowledge, as held by the author.

The author does a great job of grafting executable modeling onto the analysis/design/solution/refinement tree, but the very question assumes there is a meaningful (and useful!) answer to the question. There is not.

Consider this statement in the context of executable modeling: “Of course, other aspects of the solution, concerned with non-functional requirements or somehow tied with the target computing environment, are still left to be addressed during design.” Note the assumption that there is a meaning of the word “design.”

Now consider, as an example, a credit card company that requires that customers and merchants be billed and paid for each transaction. I would suggest that one non-functional requirement is that the customer not be inundated by bills (and that the merchant be paid as late as we can get away with Yet I would expect that to be addressed in the (executable) model of the credit-card subject matter with the addition of the concept of billing cycles, not treated as a a “design detail.”

Moreover, I would suggest that no amount of “refinement” will invent a database (or SOA or client-server or … ) Rather, these implementation technologies are invented separately, and they have their own “performance” “non-functional requirements.”

Consequently, the final, central observation made by the author that “… to answer the question [Is the purpose of an analysis model understanding the problem or proposing a solution?], the answer is both…” is 100% correct, in my, executable modeling, view.

This combination of understanding and proposing is applied recursively _at each layer in the system_. You can find a complete description in a long-forgotten paper at ooatool.com/docs/SMMethod96.pdf

@Mike

“To do this you will need a Software Architecture implemented in a Model Compiler and these are not easy and not cheap.”

I’d like to help changing that. I believe for information management systems, the same standard architectures are used by many, so there is a good opportunity for reuse/sharing the cost. Do you think an off-the-shelf model compiler is not feasible?

On it not being easy, what do you see as the main difficulties?

I’m a Shlaer-Mellor believer, although my own particular version is much evolved.

I concur with your view on Lahman’s book.

You say – “That is the first time I have seen this position defended by an expert” which surprises me since a core message of S-M/xUML over the last 25 years is to keep the Design out of the Analysis and Analysis out the design.

I’m happy you used the word Translation instead of Transformation because they are not the same process.

However, don’t get too carried away with it all – “you may get a fully specified solution after locking a customer and a modeler in a boardroom for just a day”.

To do this you will need a Software Architecture implemented in a Model Compiler and these are not easy and not cheap.

Regards,
Mike

You (and others who may have read my posts elsewhere) know that I am, of course, an executable modeling believer!

As such, let me say that I think you have characterized exceedingly well the concept of “analysis” in executable modeling approaches, and for Shlear-Mellor heritage approaches in particular. For those who are interested, in addition to the books you mention, I would still highly recommend Sally Shlaer and Stephen Mellor’s original books Object-Oriented Systems Analysis and Object Lifecycles. The notation and terminology may be a bit dated, but they are still well worth the read.

(Indeed, I first met Steve Mellor in 1993 because I enjoyed reading Object-Oriented Analysis so much that I tracked down his phone number and gave him a call to tell him how much I liked it!)

– Ed

But I wiil still need to be able to generate ordinary iteration code based on for/ifs, i.e. the generated code should run on standard Java without 3rd-party libraries.

http://code.google.com/p/infomancers-collections/wiki/Introduction
as it allows you to write Iterable’s very fast by writing it like a producer although Iterable’s data is usually pulled instead of pushed.

Actually, AlphaSimple generates a generic UI for users to interact with the prototype. Did you see that? (a BA or end user would be given a URI that showed the left pane only)

If you didn’t see it, that would show the pitch slides could give a bit more info on the “how”. I tried intentionally to focus on benefits and not on the technicalities, but I guess I went too far.

I am for using UI mockups, they do have a valid purpose, but I don’t think they are effective in getting the details in the requirements right, nor help significantly with the solution, which are the areas AlphaSimple means to serve.

Re: BonitaSoft, I will need some time to read about it before replying.

Thanks again for your help!

How do you compare AlphaSimple to, say, bonitasoft (http://www.bonitasoft.com/)?

My thought for today: Simple business with simple solutions is not that simple! ;D
Sounds good. I will twitt it!
Go on Rafael!

On business domain vs. technical requirements:

AlphaSimple is strongly biased towards business domain requirements, and for a good reason. They are the kind of requirements developers need the most help with BAs and users, they are very communication intensive. Nailing those down as early as possible is key for the project success.

In my view, technical requirements pose less of a challenge. Developers are familiar with them (as they occur repeatedly across domains), and solutions are well understood. Even though AlphaSimple doesn’t help with eliciting or validating technical requirements, it does provide an efficient approach for addressing them (with code generation). I do mention that when presenting it, maybe should have something in that regard on a slide.

On goals of AlphaSimple: note taken, will try to improve that.

On AlphaSimple being a prototyping tool. Yup, that is currently the fact that is currently available/promoted. We are working hard on the side of the equation: building (generating) the application code from a solid model.

“Where is the “user” view?”

Sorry, not sure I understand this question. Are you talking about the user interface of the application? If so, at this point that is out of scope, and users can use tools like Balsamiq for sorting that out.

Thanks again for the feedback, Vincent, really appreciated.

I fully adhere to the mission: to bring model-driven development to the masses. Still to precise what part of the mission AlphaSimple fulfills.

Have you read the MDA Guide? It’s short, and it is oldish, but still is my #1 reference for MDD:

The MDA Guide talks about “markings” and “additional information”, which are things external to the PIM that allow driving transformations.

Speaking more concretely, imagine that a tool that automatically renders diagrams (views) from models. This view will imply choices on what is included and what is left out. Imagine that those choices are configurable. For instance:

- based on the kinds of elements: only classes and relationships, or include attributes, but not operations, or only state machines.

- based on stereotypes: only classes marked as <<Entity>> (and their related <<ValueObject>>), or only elements from packages marked as <<Business>>;

- based on the PIM: only elements of packages named “*.business.*”, or something very particular such as everything directly related to the “Order” class.

IOW, one can define views that are useful for a particular viewpoint and yet don’t have to be tightly coupled with the model at hand, so they will continue to be valid as the model evolves.

Similar strategies can be applied when generating code (the “views” apply architectural patterns in that case, driving code generation).

Rafael

Since I’m fluent in Spanish (“portugues mal falado”) I was able to read it fairly easily, and confirmed that Chrome’s translation was pretty good. Unfortunately, it can’t touch the graphs (since they’re images), and that’s where much of the valuable info is found.

At present I have no scientific proven answer, only observations and educated guesses.

Our experience roots in insurance, banking, logistics and trading business (inventory management). In the projects I’ve seen, the vast majority of operations is “data shuffling”, “CRUD++”, i.e. really just creating, searching, rearranging, combining, filtering, aggregating data.

The associated operations are (more or less) straightforward, and thereby it’s not necessary to mention them explicitly in the PIM (it’s a quite different story in the PSM). There (in the PIM) the behaviour is implicitly assumed to belong to stereotypes or characterized by properties, so there’ simply no need to mention them explicitly. Even more, this behaviour cannot be captured simply as methods at the model class, since this model class maps to 10 or 20 associated technical classes, and the methods do belong there, not to the PIM-class. E.g. “create” is not a method at the PIM class, it is a method at the factory class in the PSM or below. The PIM will only contain method “snippets”, like validation formulas etc.

I’d say (just a guess) about 78% of behaviour can be captured that way (or simply derived from strutural properties, like a tight bidirectional 1:+ composition association).

The rest falls into basically two categories. The first category is “advanced data shuffling”. By that, I mean things like multistep-transactions (“wizards”), where things are selected, filtered, temporarily stored, rearranged etc. plus a bit calculations. But not really much. Concerning this category, our system is under development. We’re constantly *decreasing* it, looking for ways to better express it, since it “feels wrong” to describe it programmatically. Or at least factor out technical aspects. Like exception handling, since yes, things can go wrong, but business users don’t throw exceptions – only interpreters and VMs do that. So in the PIM I just want to express assertions, conditions, invariants. The model interpreter/compiler has to take care of what to do if these fail (and there are many possibilites, after all).

Therefore, yes, at present a procedural language is still needed, but I wouldn’t seek to improve it, but to eliminate it instead. And yes, I wouldn’t mind to have a good and general action language in UML, but I wouldn’t say it too loud, since it opens the floodgates of coding, and by doing that we will never reach the “next generation language”.

Finally, in all projects there’s a third category which will always require programming. These are core algorithms, like a simulation or optimisation or like financial math. But this category is not a problem to me, I don’t see the need to model it in UML; probably the data it operates on, but not the algorihm itself.

I am not sure why a CreateObject action cannot result in code that does everything you mentioned in your example.

Of course, not all CreateObjects represent creating objects in the database, but there are ways of identifying that (stereotypes, conventions, etc).

@Damien I tried to say something similar here in the past: http://abstratt.com/blog/2007/05/22/platform-independence-in-mda/

Well, in this case, I disagree with Martin. His observation is only true with respect to a certain flavour of MDA. Admittedly, this flavour is widespread: use your model as a 1:1 replacement for current 3GL programming.

And the argument is also true if you limit your scope to just the “action semantics language”, see my comment above.

The “Hello world” argument is very telling: Hello-world-programs are usually meant to explore the possibilities of the IO-library of a programming language, but the whole concept of an IO-library is misplaced in PIMs.

To point this out: PIM is not about IO-librabry-independence, but about IO-library-agnostics!

Real PIMs ™ are on a different abstraction level. They are not about referring to different technical platforms in a common fashion, they are just not about technical platforms at all. Proof: ask any business domain expert about IO libraries. q.e.d. This shows: it has to (and is) possible to describe systems without referring to IO libraries.

I can try, but it’s in general hard to prove a non-existence statement with an example, so maybe we can turn the tables and you give me examples of such uses, and then I try to suggest modelling alternatives? I’d really have fun to do this.

Nevertheless, here’s one example. “Creating an object” – where and when would you want to do this? A typical situation might be: the user wants to create an instance. We solved this as follows. First, there’s a socalled “CreateTransaction”. This is a standard (yet replaceable) building block which is parametrized by a factory. It manages the presentation of the factory, the validation, the db transaction and the presentation of the result, as well as sending various notifications. Sure, the implementation of the operations here requires code. But this CreateTransaction is not part of a user’s business domain model, it is part of a general interaction library instead. So, the second part is in the business domain model just to specify the factory, and to specify that you want this factory to be assembled with the CreateTransaction – which is both not expressed as code.

> An action language can/should be fully platform independent.

@should: yes, sure
@can: I’m a bit skeptic if this does not end up like Java: starting as THE UNIVERSAL language, being finally complicated and having competitors (iAlf, Alf#, …).

But I wouldn’t mind to have such a language, my point is more the abstraction level issue.

By technology, I mean the different instances of OS/hardware/runtimes/frameworks/implementation languages/databases/middleware we have presently today and that do more or less the same thing in their classes, their predecessors 5-10-20 years ago, and their sucessors 5-10-20 years from now.

Why should we accept that a solution for a domain that is not technology centric (as most are not) become obsolete just because the technology it was built on is being replaced for newer ones? Or why should we not be able to move the solution across competing technologies (Java->C#, Oracle->MongoDB). Or why should we have to do a lot of work when we want to make an architectural/design improvement (even if the technology stack was not altered). Or why should the technology I want the system to run on determine how developers build the solution, or vice versa?

Re: code vs. model, it is not really clear cut, so it is hard to draw the difference between them based on isolated aspects. Overall, here are traits that IMO make something more a modeling language than an ordinary programming language:

the level of detail required to specify a solution is less than an ordinary implementation language typically requires
more conducive to specifying the what instead of the how
having transformation to other (programming) languages as a primary use case (sure, it is technically possible to execute a model natively, and one could always write a tool that translates between any language A and B)
supports the concepts from the domain directly (if a DSL) or, if a GPL, supports high level conceptual modeling without requiring language extensions (state machines, associations, signals)

Those are the signals I could come up with now. There are probably more.

However, I’m still not confident with the distinction between model and code. You advertise that a model is not necessarily graphical. You also say that modeling allows to be technology agnostic. What do you exactly mean by technology? If I use a programming language with a VM, I’m already platform agnostic (e.g., my Java code can run on Linux, Windows, and MacOS). Is it important that my project can run either on Java and C# (if it is what you mean by technology)?

An action language can (and should) be fully platform independent. I accept that the OO paradigm (even if at a higher level of abstraction) won’t always cut it, and a DSL will be a better solution. But I think that depends on the context (domain/application/users).

The approach of executable modeling does not force you to model everything. You can still combine generated code with hand-written code.

Also, whether to model or to code is not a clear cut decision. If the level of abstraction your domain requires is best provided by an ordinary programming language (and their tools), and there is no interest in having the solution be implementation technology agnostic, there is no reason for modeling. If that is the case, by all means solve it in code.

Sometimes that is not very obvious to assess though. People will confuse “best suited for” with “can do” (all implementation languages can do anything a modeling language would be best suited for) without realizing the consequences.

Not saying that is your case, but it is a typical reason why executable modeling will be dismissed. For your case, you need to look at several instances of the hand-written code that is extending generated code and ask yourself if there isn’t a pattern and if concerns the code deals with couldn’t be better dealt with at the model level.

And UML is not only a language for people. It is a language for tools as well. And different people and use cases will have different needs. The clear separation between concrete syntax (the notation) and abstract syntax and semantics is intended to allow sharing much of the value of the language while providing the best notation for the use case at hand.

@Daniel care to explain, maybe with a concrete example?

You can specify behaviour in UML. And in the case of generated behaviour, you can drive variation based on the model.

But that leads to a new problem: For many test cases, you’ll need to specify different type hierarchies. So you’ll end up with several similar copies of all generated classes.

The problem is that many OO languages don’t perform well when you start to mess with the inheritance. Languages like Python allow you to modify the behavior of an instance after is has been created (by adding or removing methods and fields from it).

In Java, you need workarounds. It’s a limitation of the language, really (or rather of the slow CPUs of the past). Today, it might be possible to rebuild type inheritance using proxies and interfaces and large proxy caches at runtime. The idea here is that you wrap an instance with a proxy at runtime (for example with byte code instrumentation) and then save it in a cache, so when you need the same proxy type again, you can ask for the existing proxy instance.

Confused? Say I need to add the method foo() to an existing instance. The solution is to create an interface with foo() and then a wrapper which wraps an existing instance with an implementation of the interface. To be able to have state in foo(), we need to cache the wrapper.

I’m not really a fan of tools that “know” which lines a user has changed because that can break. And if it breaks, you’re in deep trouble. Something explicit is much better. It also allows you to undo changes – with a tool, you not only need to restore the original code but you also need to tell the tool to forget about the change you just made. And you better not make a mistake or ugly things will happen.

In the end, it all boils down to being unable to build software from smaller blocks than classes. If we could say “take this instance and replace the method foo() with that one”, such things wouldn’t be an issue at all.

Just one remark concerning ways of behavioural modelling. Due to our experience with our EM/OS system, depending on the abstraction layer (CIM/PIM/ASM/PSM…) the needs for behavioural modelling are quite different.

While in a PSM an action language with capabilities to create objects and throw exceptions might be a useful thing, in a PIM this is just not the right abstraction, except for minor usecases like expressing a validation formula (even then, it might be better to have a validation library at hand and refer to named rules).

Sure, in reality there’s always the point where your abstraction fails and you need a fallback and hack some code into your model, but this is not 80/20, it can be reduced to 99/1.

More details about our approach can be found e.g. in this thread http://www.modeldrivensoftware.net/forum/topics/can-you-really-use-uml-to

Andreas

So Ted can make changes to custom code blocks without re-generating the entire model.

context AccessLogParser as Access { … }
context IP2Profile as Profile indexed by ip as IPAddress { … }

context AccessingProfile as IdentifiedAccess {
interaction {
when provided AccessLogParser
get IP2Profile
always publish
}
}

From such a description, a code generator produces a programming framework which includes the following abstract method declaration:

abstract IdentifiedAccess onNewAccessLogParser(Access access, PullFromIP2ProfileCallback ip2Profile);

This can then be implemented, in a subclass, by a Java developer like this:

@Override
protected IdentifiedAccess onNewAccessLogParser(Access access, PullFromIP2ProfileCallback ip2Profile) {
Profile profile = ip2Profile.get(access.getHost_ip());
return new IdentifiedAccess(access, profile);
}

Here, you can see that my approach leverages partial code generation; the developer is really guided by the generated code, i.e., the programming framework contains types dedicated to help the developer in implementing the architecture as described by the architect (e.g., PullFromIP2ProfileCallback which hides an RPC call to a remote object). Also, this approach leverages existing tools (IDEs, Java type checker, Java libraries…). For example, the developer only needs to use parameters of the abstract method and code completion to do his job. Have a look at the slides on my website if you want to know more about my approach.

With the executable model approach, if I understand it correctly, it would not be possible to guide the developer or leverage existing general-purpose programming language tools. What do you think?

Totally agree. Don’t model what you should be coding. But the converse is also true.

Hope that Ted, by the end of his journey, will have a reasonable understanding of what is best to model and what is best to code.

@Jan: Pointer was appreciated.

@Filipe: I think he should at least be aware of that option.

@Gonçalo: If you had included a link at least I could claim a referral fee…

Any good and scalable code generation tool will for sure keep trace of human added code from a generation to another (my favorite is http://www.mia-software.com/en/products/mia-studio/ ;D).

Ted will certainly soon discover one of the 10 productive MDD best practices: don’t model/generate things that are much simple to code/maintain! (keeping generation for his DRY goal)

But Ted’s very next move may be to subclass NON generated code…

The subclassing is also known as generation gap pattern and you can also use it with EMF:
http://www.slideshare.net/meysholdt/codegeneration-goodies

(and avoid JMerge)

regards,
Moritz

In java, for subclass, from my POV the best approach is to have several source folders, one for the generated code, one for custom code.

I better know about Eclipse EMF/GMF. The way that we are using in my team is to have a plugin for the generated code and another one for the custom code. Why? because plugin.xml and MANIFEST.MF are also generated and we can’t have twice of them per bundle.

@Rui I just tried quickly AtomWeaver so I surely missed a lot of things.
“no problems with his hand-written code.”
The hand-written code is set in your own editor. You can’t use your favorite IDE easily.
“true model-based generator can re-read the model and generate again”
It implies that you respect the convention in the generated code, the marker to delimit generated from non-generated code.
Respecting markers and conventions, a lot of generator have reconcilier to do that I think (GMF with @generated NOT, Acceleo with User code blocks,…)
And for regeneration, if someone modify the custom part of code in the generated code, are you taking it or keeping the custom code stored in the model (that might have been modified also)?

@Raphael
Yes, let’s see the walkthrough of Ted and to which solution he will go.

So, using ABSE Ted has no problems with his hand-written code.

Regarding regeneration, any true model-based generator can re-read the model and generate again, so that aspect is a non-issue IMHO.

In C# there is also the possibility of using partial classes to seperate the generated code from the user-implemented code.

My 2 cents

- jump to EMF
- subclass generated code
- modify templates for generation
- use aspects on the templates for generation
- use aspects on the generated code (AspectJ, ObjectTeams)
- use anootations to tell to keep soem part of code and so write a reconcilier (oh no I don’t like this method)

And sure they are another.
Let’s see what Ted will use

Haha, that was fast!

I am using UML to appeal to a more mainstream audience, but the intention is that the fundamentals should apply to any metamodel.