100% Code Generation From UML

When organizations chose to develop software using UML and code generation, typically only the static model is used to generate the code, resulting in the structure of the code being the only part automatically created. Unfortunately this leaves a large portion of the implementation not generated and the software engineers with the task of ‘filling in the gaps’.

Objektum Solutions have created a UML modeling environment, using Atego Studio on a number of projects that enables the dynamic (or behavioral) aspects of the design to be auto generated.  This means that 100% of the code can be generated from the UML model with the additional benefit of the model and code always being synchronized.

 

The UML2 Activity Model has been used to model the dynamic behavior of operation bodies and a bespoke code generator has been developed (in partnership with Atego) for both Ada and the C programming languages. Objektum Solutions have also developed a reverse engineering capability so that Activity models (including diagrams) can be automatically created from source code. 

Below is a simple example of an activity model and the auto generated c code.

 

If you would like more information or if you would like Objektum Solutions to help you achieve 100% code generation and full synchronization, please contact us at:

Email: info@objektum.com
Telephone: 0845 199 9932 (UK)

Model Driven Development: Past and Future

In the first in a series of interviews about UML and Model Driven software, Todd speaks with expert Rafael Chaves of Abstratt Technologies to find out his opinion on model driven development...

Todd Humphries: Did you have a 'Eureka!' moment when modelling made sense for the first time and just became obvious or was there one particular time you can think of where your opinion changed?

Rafael Chaves: When I was first exposed to UML back in school it did feel cool to be able to think about systems at a higher level of abstraction, and be able to communicate your ideas before getting down to the code (we often would just model systems but never actually build them). The value of UML modeling for the purpose of communication was evident, but that was about it. I remember feeling a bit like I was cheating, as drawing diagrams gave me no confidence the plans I was making actually made a lot of sense.

After that, still early in my career, I had the opportunity of working in a team where we were using an in-house code generation tool (first, as many have done, using XML and XSLT, and later, using UML XMI and Velocity templates, also common choices). We would get reams of Java code, EJB configuration files and SQL DDL generated from the designer models, and it did feel a very productive strategy for writing all that code. But the interesting bits (business logic) were still left to be written in Java (using the generation gap pattern). It was much better than writing all that EJB boilerplate code by hand, but it was still cumbersome and there was no true gain in the level of abstraction, as we would model thinking of the code that would be generated - no surprise, as there was no escaping the facts that we would rely on the Java compiler and JUnit tests to figure out whether the model had problems, and in order to write the actual business logic in Java, we had to be very familiar with the code that was generated. So even though I could see the practical utility of modeling by witnessing the productivity gains we obtained, there was a hackish undertone to it, and while it worked, it didn't feel like solid engineering.

It was only later, when I was doing research for my Masters, and I was finally exposed to the approach of executable modeling and MDA, that I finally understood there was authentic value to modeling. Real gains in level of abstraction. Validation and execution of models long before a target platform was even chosen. Full code generation, including business logic. Ultimate platform independence. It finally made all the sense in the world. It made so much sense to me that I could not believe that was not how everybody was writing software. Since then, I have been obsessed with building tools to help bring the approach to the mainstream.

TH: What would you like to see in future versions of the UML standard? What do you think UML is lacking that would help MDD progress?

RC: I actually wrote a post about this a while ago which I think addresses that exact question:

http://abstratt.com/blog/2010/02/08/uml-may-suck-but-is-there-anything-better/

TH: You've written in the past about misconceptions and myths you've come across trying to promote MDD, in your experience is it usually experienced software engineers or new graduates who are the most accepting of  modelling principles and why do you think that might be?

RC: Talking specifically about MDD (and not modeling in general): I think in general less experienced developers will buy into MDD more easily than more experienced developers. More senior folk will tend to resist more to the idea that the much of what they do (and are very proud of) could be done automatically.

Re: modeling in general - I, for one, will resist to the idea of modeling as something inherently beneficial - unless your models are actually what drive the software development (they are the primary artifacts), I see modeling as superfluous and wasteful.

TH: Do you think MDD is easier to pick up for someone who has little to no 'real-world'/practical experience of software development or for those with many years traditional development experience?

RC: Hard to say - I do think experience is usually beneficial, and a more experienced modeler will in general produce better results than a novice modeler. OTOH, I think it is much easier for a novice developer to build high quality applications using the MDD approach than manually crafting the application (because MDD allows you to encapsulate and reuse skills/expertise).

TH: Are there any books, blogs or other sources that you would recommend for someone new to or inexperienced with MDD?  Any tips of your own or those that helped you that you'd care to share?

RC:

Read the MDA Guide 1.0  

Join the ModelDrivenSoftwareNetwork
Read about Executable UML
Follow @seidewitz on Twitter
H. S. Lahman recent book (Model Based Development)
Markus Volter book on MDSD is a good introduction as well.

Study the codebase of enterprise applications in Java or C# (or even RoR) and look for the implementation patterns 

Look at an application and learn to consciously separate problem domain concerns (which are implementation independent) and solution domain concerns (which are implementation specific)

TH: Back in November last year you said "I think we still live in the dark ages of software development And, what is your vision or dream of how software development might look in ten years? Twenty?

RC: We would use a language that is at higher level of abstraction than 3GLs which would allow us to naturally express technology independent solutions, and then target different platforms with ease. The target platform won't put constraints on how we reason about solutions, and the development tool we use won't put constraints on what platform we target.

There will be a market for reusable business applications (which can target multiple platforms), and a market of target platform-specific code generators (which can accept applications from different domains).

 

This is a great introduction to UML for beginners as well as being interesting to those who are working with executable modeling and been through it all... 

Thank you Rafael for such considered answers and creating a great read!  

Interview: Overcoming Migration Challenges

Companies across the globe are continuing to allow legacy technology negatively impact their business because they either don’t know what to do or feel it is too risky or costly to modernise their applications. The reality is that there will come a point when they cannot ignore it anymore and they have to do something about their legacy systems.

Using the Legacy Bridge technology, one of our customers carried out a HOOD and Ada83 migration in to UML and Ada95 so that they could enhance existing their safety critical systems. We asked them about the migration and how they used technology to overcome their challenges they faced.  

What was the main reason for migration?

There were three main reasons:

1. To have a single toolset for both Software Analysis and Software Design work
2. To reduce the number of toolsets in use on the project (thus reducing maintenance renewal costs)
3. To move to a company preferred toolset
4. To increase integration with other company preferred toolsets (i.e. DOORS and Dimensions CM)

What were the alternatives to using Legacy Bridge?

The Rhapsody in Ada inbuilt reverse engineering tools or to develop our own in house migration tools however this was deemed early on to be too expensive.

What was the deciding factor to choose Objektum Solutions and Legacy Bridge to migrate?

Objektum Solutions had already been through similar exercises of migrating from CP-HOOD to UML albeit to a different UML toolset with another organisation similar to ours. Legacy Bridge has the facility to bring across our HOOD artefacts, as well as synchronising the design with the current code.

What time savings did Legacy Bridge bring?

Once it had been proven that Legacy Bridge could correctly analyse our HOOD and our Ada, the process of migration and synchronising with the code took only a couple of hours per model.

And, how was it working with the team at Objektum Solutions?

The support provided by Objektum was excellent, with most problems being resolved with days (if not hours) of being reported.  This enabled us to keep up the impetus of the migration process without have to wait too long for tool updates 
 

Another colleague also commented saying "The turnaround time for problem resolution was exceptional. This has been possible with the tremendous knowledge the team have of the product including HOOD, UML and Ada."

What benefits does migrating to UML give you for the future?

We now have both our software analysis and software implementation models in the same toolset; with both of these models integrated with our requirements database and our configuration management system.  All three toolsets are “current” toolsets widely used across the company and across industries.

Will code generation be a consideration going forward?

Code generation has to be ultimate aim; but for now we are happy that what is in Rhapsody can be shown (via the compare functionality) to be a reasonably accurate representation of the code.

Model Driven Software Modernization

We’ve created an innovative solution to Legacy Migration and we’re going to let you in on how the our model driven software modernization technology works… 

He just learnt about the Bridge Technology...

With the ever growing need for organisations to develop robust software in a more rapid and cost effective manner; many projects are seeking ways to protect the investment in the existing software systems that are critical to the success of their projects. Over time external influences such as hardware, platform or skills obsolescence create a substantial risk to a company's on-going success. In addition, many legacy tools do not provide engineers with the ability to keep the design and implementation synchronised, which results in the code base deviating from the design, making the design obsolete.

Migration is a daunting task full of risk and projects are increasingly demanding solutions that can be deployed at a fraction of the cost of developing a new system from scratch and that reduce the risk. 

We have employed and model driven approach and developed a suite of innovative migration solutions to address this growing need. 

Using our intuitive rules based parser, which uses standard Backus Normal Form (BNF) notation, engineers can quickly and easily adapt our technology to analyse the syntax and semantics of any source model or legacy code. A meta model is then automatically constructed to provide an accurate representation of the source information which forms the basis on which any transformation can be performed.

Using our model to model (M2M) transformation technology the meta model is used to automatically produce a UML model in virtually any toolset. This approach provides the opportunity to refactor the legacy application as required by the needs of the business. Many modern UML tools provide the ability to generate customisable code. By automatically migrating the legacy application into UML a code generation strategy can now be adopted to leverage the benefits of modern programming languages.

If refactoring is not a project requirement then our unique model to text (M2T) transformation capability provides a direct path to language translation without the need for an external UML modelling tool.

Our revolutionary model driven approach to legacy migration provides several benefits:

• Easily configurable analysis of legacy applications using a rules based parser
• Elimination of human error inherent in manual migration strategies
• Significant reduction in time and cost for new technology adoption
•  Removes dependency on legacy skills and tools
•  Reduction in future software maintenance costs
• Mitigates obsolescence issues
• 100% automatic code generation

Our tried and tested approach has already been successfully deployed on several major pan-European safety and mission critical projects. When it comes to building bridges between legacy data and modern technologies we at Legacy believe that we are miles ahead of the competition and that’s why we’ve called our solution the Legacy Bridge Suite.

At Objektum we are committed to model driven development and so all of our products are 100% code generated from UML models as we believe that we have no right to promote a technology that we haven’t proven ourselves.

We will be running live demos of the Bridge technology from this month, so contact us to arrange one for you and your team...

Myths that give Model Driven Development a Bad Name

We are proud to introduce the first blog post from our new guest Blogger, Rafael Chaves, founder of Abstratt Technologies...

It seems that people that resist the idea of model-driven development (MDD) do so because they believe no tool can have the level of insight a programmer can. They are totally right about that last part. But that is far from being the point of MDD anyways. However, I think that unfortunate misconception is one of the main reasons MDD hasn’t caught on yet. Because of that, I thought it would be productive to explore this and other myths that give MDD a bad name.

Model-driven development myths

Model-driven development makes programmers redundant. MDD helps with the boring, repetitive work, leaving more time for programmers to focus on the intellectually challenging aspects. Programmers are still needed to model a solution, albeit using a more appropriate level of abstraction. And programmers are still needed to encode implementation strategies in the form of reusable code generation templates or model-driven runtime engines.

Model-driven development enables business analysts to develop software (a variation of the previous myth). The realm of business analysts is the problem space. They usually don’t have the skills required to devise a solution in software. Tools cannot bridge that gap. Unless the mapping between the problem space and solution space is really trivial (but then you wouldn’t want to do that kind of trivial job anyways, right?).

Model-driven development generates an initial version of the code that can be manually maintained from there on. That is not model-driven, it is model-started at most. Most of the benefits of MDD are missed unless models truly drive development.

Model-driven development involves round-trip engineering. In MDD, models are king, 3GL source code is object code, models are the source. The nice abstractions from the model-level map to several different implementation artifacts that capture some specific aspect of the original abstraction, combined with implementation-related aspects. That mapping is not without loss of information, so it is usually not reversible in a practical way, even less so if the codebase is manually maintained (and thus inherently inconsistent/ill-formed). More on this in this older post, pay attention to the comments as well.

Model-driven development is an all or nothing proposition. You use MDD where it is beneficial, combining with manually developed artifacts and components where appropriate. But avoid mixing manual written code with automatically generated code in the same artifact.

What is your opinion? Do you agree these are myths? Any other myths about MDD that give it a bad name that you have seen being thrown around?

Rafael has been writing code since he was in high school (20 yrs ago), and with time he discovered he was way more interested in how software was built than what the software actually did. For the last 8 years, he has been focusing on model-driven development, and as a result, he has built two products out of that: TextUML Toolkit, a UML modeling tool for Eclipse that uses a textual notation, and AlphaSimple, an online modeling environment that supports prototyping and code generation (currently in beta). Rafael is a keen blogger and also has a blog as he aims to stop people writing so much code... We collaborated because Objektum Solutions  are also on this quest.

UML and Model Driven Development, a beginner’s opinion

Todd, a bright young software developer and the latest addition to Objektum explores the common perception of UML and shares with us why his view on UML has changed... 

Having recently joined Objektum after graduating last year, the team and I thought it would be a good exercise to write down my initial impressions of the work I do with UML class modelling and how it relates to software engineering, as much for your benefit as my own.

It might first be a good idea to give you an overview of my level of exposure to UML before joining the team. The truth is that I was only offered modules covering UML during the first year of my degree and despite choosing advanced programming options in later years the subject wasn’t approached again.

It was very much my experience that we were being taught UML without it ever being explained as to what exactly it was useful for, or how it might be applied to a real-life situation.

One example that I’m sure will be familiar to anyone who has studied UML is modelling a video rental scenario. We would study a text and find the actors and use cases to create a Use Case diagram but then we would move onto the next topic. The step between using the model to conceptualise the problem and actually creating the system was never taken.

It left me wondering just when UML diagrams were actually supposed to be used: should they be used in the planning stages, as a way or document functionality after the fact or as a high level overview for explaining a system? Suffice it to say that I couldn’t immediately tell you the benefits of modelling.

Something that I think my lectures would have benefitted from and something that was quite surprising to me when being shown around the tools and systems we use here in the office is just how easy it is to generate code directly from class diagrams.

Now you might be thinking that it’s a doddle just to sit down and write a skeleton class and start adding methods and attributes and all the rest of it by hand as-and-when you need them, but think about how much longer it would take if you later realised that you needed to inherit from another class.

Traditionally you would have to go to each affected class and add the changes by hand, taking up valuable time and presenting an opportunity for bugs to creep in. Automatically generating classes from a UML model means that all the hassle and potential problems you might otherwise encounter are completely side-stepped and the same task can be accomplished in much less time. Not only that but creating accurate class diagrams makes discussing and reviewing much easier, and you can quickly sketch a diagram on a whiteboard or paper and know exactly what’s going on without the need for pseudo-code.

I don’t expect to have sold you on the idea of using UML in your project quite so easily but I do hope after reading this you’ve at least come away with the impression that UML isn’t just a tool for making diagrams with funny stickmen on, and if you’re hesitant to give UML a chance then it might just pay to ask yourself why, and to look at where your preconceptions come from.

When I mentioned to friends that I was using UML in software development they were very curious as to what exactly I used it for- the general comment being ‘Oh do people actually use that?’. To me it seems to highlight a real problem in the way that UML is currently taught, a problem that only serves to keep model driven development as a fringe activity. 

In keeping with the university theme, if this were a lecture this is around the time that I would mention some dusty books for you to go away and read (that you would ignore) so if you’re interested in learning more about how good use of UML can be a positive influence on your software project you could do much worse than this well written and practical essay by Leon Starr.

UML Survey: How is UML used?

Our friend across the pond, Bob Maksimchuk is a Principal Consultant at Project Pragmatics conducted a simple survey into how UML was being used. We found it fascinating and it generated some interesting discussion. Have a read and let us know your thoughts!

  

The UML Survey Results Are In

In April, I invited one and all to participate in a simple survey to see how they are actually using the UML on projects.  Is it really mainstreamed?  Is it still in the adoption phase?  Or is it in decline?  The survey is now closed.  Thanks to those who participated.  Here are the results.

The first question asked how UML was used on projects.  (See results in Figure 1.)

 

Figure 1

The results indicate that the use of UML is very strong in the early part of the project lifecycle.  But once design is elaborated enough, it seems that’s it…on to code.

Second, I asked what diagrams were typically used.  (See results in Figure 2.)

 

Figure 2

These results seem to support the results of the first question, with use case and class diagrams being heavily used, followed by activity diagrams.  I find it interesting that sequence diagrams are used only slightly more than state machine diagrams!  State machine diagrams were used lightly in the past, specifically by those who build things that are time / state critical (medical devices, aerospace, etc.).  Maybe their increasing popularity is tied to the renewed interest in system engineering that I am seeing in the marketplace.

Last but not least, I asked people to rank their organization’s UML expertise.  (See results in Figure 3).   

                    

Figure 3

I find it very interesting that after all these years, with over 3000 UML books having been written, all the webinars, conferences, and so forth, that nearly half of the people still know little or are still learning about the UML. 

So what do you conclude from these results?

  

Our Technical Director Derek took 5 minutes out of his day to give us his opinion on this survey:

 

This is an interesting survey and I agree that your conclusion about adoption of UML in the early phase of the lifecycle seems accurate.    Given the result, I am surprised that class diagrams are one of the most commonly used notations, I can only assume the results show class diagrams being used during the analysis phase.  Maybe the survey should be repeated with an additional question about where in the lifecycle the elements of UML are being employed.

It would appear that UML is not being fully adopted during the detailed design and implementation phase.  I wonder why? 

At Objektum we find significant benefit in terms of time and cost, when adopting UML to drive our code generation.  In fact all our development uses UML and code generation techniques which improve our productivity, quality and overall maintainability.  I wonder if the reason that others are not adopting a similar strategy is owing to a lack of training in code engineering as well as misconceptions about the maturity of modern UML tools.

I am confident that if other developers adopted an approach similar to our own, we would see a significant shift in the survey result.  I would be interested in hearing from others on the use of code generation, particularly those who have not had a positive experience.

 What do you make of the survey? 

Bob Maksimchuk is a Principal Consultant at Project Pragmatics, LLC.,  specializing in helping software development teams GET WORK DONE by introducing: PRACTICAL techniques, STREAMLINED process, and FOCUSED training and mentoring, all specific to your team's needs.  Visit now at http://www.ProjectPragmatics.com.  All rights reserved © 2009-20011 Project Pragmatics, LLC.

.

Social Network for Model Driven Software Development

Cat is pretty clued up about what is happening on the World Wide Web and often points us in the direction of interesting blogs and online networks so we thought we would share what she tells us with you...

The Model Driven Software Network

Created on Ning (a site which lets you create your own social networks), The Model Driven Software Network is a vibrant community of those interested in, yes you’ve guessed it, Model Driven Software Development and we were amazed by the number people who were using it. Social networks can sink or swim as it is dependent on the users’ contributions. This one seems to be flying. 

As creator Mark Dalgarno puts on the site:

The Model Driven Software Network is for anyone who's interested in Model Driven Software Development (MDSD).

You could be a practitioner, a researcher or just plain curious about what MDSD is about and how to get started.

The topics you'll find discussed here relate to the process, practice, technology or people issues involved in developing with models. This could include:

• Domain-Specific Languages
• Domain-Specific Modelling
• Model-Driven Architecture
• Executable UML
• Eclipse Modelling Tools
• Code Generation and Model Interpretation

Sign up and explore it for yourself if it sounds like something you’d be interested in and don’t forget, you get out what you put in. Our readership is growing everyday (way above what we ever expected!) so comment on this post and let us know what you have found online that might be of interest to other software and systems engineers…

Stakeholders Don’t Just Kill Vampires – Sometimes They Talk

Alex continues to blog valuable insights into the art of capturing requirements...

Typically requirements analysis begins with some sort of user requirement document (URD) and often engineers consider this to be the only source of input. In modern development, however, customers are producing fewer requirements but, instead, becoming more capability driven. What this means is that, rather than identify a long list of “The system shall…” statements, customers are identifying gaps within their capabilities and asking industry to propose an appropriate solution. In order to effectively handle this absence of a URD it is vital that engineers take the time to identify and investigate the needs of the system stakeholders.

 So what is a stakeholder? As my title suggests, in this context, it is not Buffy the Vampire Slayer; nor is it the waiter at your favourite restaurant. A stakeholder represents anyone who has an interest in the system for some part of its development or operation. The obvious stakeholders are those who are paying for its development and those who need to use the system but is that where it ends? What about internal stakeholders? I know that whenever I develop anything that Derek looms over my shoulder wanting to know if the deadline will be met and whether I’ve blown the budget or not (naturally I never do). As a requirements engineer I have to take into account, not only those whom the final product will be delivered to but also those who will take my work and further the development; designers, implementers, testers – they are also my customers.

Successful development is based on good communication. Regardless of how your system functions, the project has failed if it doesn’t meet the needs of your stakeholders and the only way to guarantee that it will is to involve them in the development process all the way through. Learning how to ask the right questions is as important a development skill as understanding the technology on which the system is going to be based.

Alex

Use (less) Cases

Alex travels around the world teaching organisations about creating systems and how to use Use Case diagrams effectively. A huge percentage of people are sceptical about Use Case Diagrams but in this new series of posts he is going to be teaching us how to use them to make a difference in our work...

I love use cases. I love teaching them, writing them; in fact I love everything about use cases, well almost. What I really don’t like about use cases is the frequent way in which they are poorly introduced into an organisation. 

At Objektum Solutions we talk about the “use case hoax”; the fact that many people focus on the “stick men and bubbles” while failing to understand the underlying concepts of use case development. For us use cases are not about the notation but about the thought processes that are employed in their development.

One of the problems that I often encounter is the inability of engineers (particularly those who have spent years at the detailed design or implementation level) to abstract their thinking in order to express how the systems they develop will be used in the real world. All too often I find use cases that are developed purely to “tick” the relevant boxes and therefore add little or no value.

As with any new technique (and by new I am speaking from the relevant point of view of the deploying organisation as use cases have become an old friend to many of us), careful consideration has to be given to how to introduce use case driven development.

In order to successfully apply use case modelling to a project, engineers must first be taught why they are doing it and what the expected result is. For me use cases offer more than just an understanding of how the system under development will be used. They are a means of discovering what questions need to be asked of the stakeholders in order to ensure that a project is suitably equipped to move the development effort forward.

Over the years I have taught many aspects of software and systems engineering but there’s still nothing more gratifying that the look, at the end of a use case course, which clearly says “wow, I never realised how powerful this technique is”.

As a consultant it is my job to teach people modelling languages but as an engineer it is my mission to teach people how to model.

Alex

The Evolution of Code Generation

Derek, our Technical Director, has been working in software development over the last 25 years and set up Objektum Solutions over 10 years ago. He reflects in our latest post about whether we have learnt from the past with regards to code generation...

 When I started my software career, it was common place to develop code in low level assembler languages such as Z80, 6502, 68000 etc.  We had little or no design methods, development tools or strict processes to follow. Ensuring we met even what requirements we did have, was difficult and code reviewing was a labour intensive task that often resulting in a “ticking the box” exercise?  

I remember working for a company that introduced Ada83 for the first time and being involved with the compiler vendors, helping to pick the bugs out by looking at the assembler being generated.   I remember people saying “I don’t trust this code generation” way of doing things; that seems so long ago nowadays we trust the compiler put in front of us.

As software systems become even more complex, there is an increasing need to find alternative development techniques compared to the traditional low level methods and high level programming languages we have become used to.  This is necessary to ensure we maintain quality, adhere to requirements, increase productivity and do not increase the workload of project managers. 

Model Driven Development

Model Driven Development (MDD) is the next step of abstraction in writing software applications which are traditionally written in programming languages such as Ada, C++ and Java.   If we look back in the history of software development, we will find that each higher level of abstraction adopted has offered improved productivity and ease-of-writing complex applications i.e. moving from assembler to high-level programming languages.

MDD focuses on creating models, or abstractions, more closely related to domain concepts rather than computing (or algorithmic) concepts.  Typically models are constructed to a certain level of detail, and then code is crafted (even sometimes by hand!).  With the introduction of the Unified Modelling Language (UML), MDD has become very popular today within many industry sections such as Telecommunications, Finance, Defence etc. and there are now a wide variety of practitioners, supporting tools and processes.

• The advantages of MDD include:
• Improved communication of the design(including to the customer)
• Increased understanding of design elements
• Enhancing the consistency between design and code
• Traceability within the software design
• Increased productivity through efficiency 

Code can be generated from the models, ranging from system skeletons to complete, deployable products.  However, I am experiencing déjà-vu. Once again I can hear people say “I don’t trust this code generation”.  I wonder if in ten years we will simple trust the code generators put in front of us.

I have been working with UML for the last 10 years and in the subject of code generation and reverse engineering intensively for the last 5 years, and I’m looking forward to writing my next post and sharing my experience in developing reverse and roundtrip engineering tools. 

Derek