Friday, 30 September 2011

When the Bough Breaks – Alternate Scenarios

Alex returns with his blog post series on understanding use cases... 

Wow, it’s been four months since I wrote my piece on primary scenarios so this is severely overdue. I choose to blame this on the fact that one of our account managers, Ajay, appears to be offended by the idea that my calendar can have days in it that have no entries at all and does everything in his power, successfully I might add, to account for every minute of every day of my life. This has actually become something of a joke with many of our customers who, when asking me if I’m available to do something, “understand” that I must first get permission for Ajay before replying. Enough about my scheduling situation, were here to talk use cases

 Our previously defined primary scenario details the required behaviour of the system under “ideal” conditions and is useful in the understanding of customer requirements. The thing about customer requirements is that, even the most thoroughly defined, requirements are likely to only specify the nominal behavioural flow. Most of the customer requirements that I have read are significantly lacking in detail when things don’t go according to plan.

The use case primary scenario provides us with a clearer understanding of what it is that our customer requires but what about the things that they didn’t take into account? It is here that the alternate scenario provides answers or, in the case of most requirements, questions that need answering.

The identification of alternate scenarios is a three step process:
  • Run through each step in the primary scenario and ask yourself; “what could happen differently?” to produce a list of potential alternate conditions
  • Rationalise the list by removing those that the system cannot or does not need to handle and merging the ones that will be handled in the same way
  • Write the scenario for each condition in the rationalised list.

During the identification of alternate conditions you should be looking for things such as:
  • Incorrect behaviour on the part of either the primary or supporting actors
  • Timeouts; one of the actors failing to provide a required interaction

When writing an alternate scenario the alternate condition becomes the trigger and then all we have to do is write what happens next until one of two things happen; either the primary scenario is re-joined or the use case ends because the goal cannot be achieved.

Typically the documenting of alternate scenarios is where use cases provide the most benefit in highlighting the inconsistency and incompleteness of the customer requirement.

Finally one should repeat the process on each of the alternate scenarios to identify possible alternates upon the alternates. Obviously this could be applied recursively through many levels however I tend to find that if you need more than two layers of alternates you should reconsider the scope of the use case as it is highly likely that you have attempted to include multiple capabilities that should each have their own use case.

Even with only two layers of alternates it is possible to develop far more scenarios than are actually needed, so, be sure to always question if what you are writing is adding to the required understanding of the system under development.

Next time I’ll look at how we model common and specialised behaviour in our use cases.

Friday, 23 September 2011

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:

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?

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!  

Tuesday, 20 September 2011

Joe's Database Delight

Joe becomes more of a computer nerd with each passing day.
 Trainee software engineer, Joe learns about databases and continues on his journey into becoming a real software wizkid...

The last couple of weeks have been a very steep learning curve in my programming process. I have had some intense lessons in things such as databases and VB6. I started to get a little more confident in my programming abilities, being able to make small functional programs that did simple task. 

I got to this stage and thought I was clean sailing from there and thought it would just be more of the same stuff for a while. Wow, was I wrong! I was given the on-going task of taking over and maintaining our in-house administration tool. This tool was made in VB6 some years ago and we saw it as the perfect project for me to expand my existing knowledge and give me the chance to work on a project that would actually be very beneficial to the company. The first thing that I did was spend a day just trying to get my head around the tool. It was totally new to me and the project just seemed huge. Once I had spent a day or two studying the code and which paths different functions were taking I started to understand how things were working a bit. 

The next step was to actually try and make some changes to it. The first couple of changes I made were very simple but all the same I thought I was doing amazing actually being able to change something for the better in a project of this size! All I was doing was changing the maximum amount of characters that could be entered into a text box. After I had made these changes I was given the task of automatically generating an email and populating it with a subject, a set of email addresses and with a body of text. 

My first lesson was a quick but informative lesson on databases. Derek and Todd ran me through how a database works, how they are linked together and how to call information from the database using queries. Once I had learnt that it was then time to try and pull everything I had learnt together and with a bit of help from Derek I managed to make the function that did exactly the right job that we wanted to achieve. I was so happy with the progress that we had made and that I had made a working function that would be largely beneficial to the company. 

This was not the end though. Although I had thought it was ready to be published and become part of the company’s in-house tool, I was wrong. We discussed making it into a HTML email. It was like being put back to square one again as I knew absolutely nothing about html emails. After doing some research and spending some time with Fiona we came up with the html email that we wanted to be in the body of the email. We then worked out that if we wanted to change the body of the email we didn’t want it to be hard coded into the function. We decided to make the function take the contents of a document which contained the body of the email so if we ever want to change the email we just had to replace what was in the document. 

So, there it was, my first big change to the company’s most important in-house administration tool. Needless to say I am very happy with what I have achieved over a short period of time and I can’t wait for what is next.

Needless to say, we're impressed with how much Joe has learnt since being with Objektum Solutions and proud to have him on the team! 

Thursday, 15 September 2011

Engineers with a Sense of Humour

As Summer fades into Autumn, we bring you a post that we found on the world wide web to brighten up your day... 

After every flight, pilots fill out a form, called a gripe sheet which tells mechanics about problems with the aircraft. The mechanics correct the problems, document their repairs on the form, and then pilots review the gripe sheets before the next flight. Never let it be said that ground crews lack a sense of humor. Here are some maintenance complaints submitted by pilots and the solutions recorded by maintenance engineers. By the way, the airline these came from the only major airline that has never, ever, had an accident.

Pilot: Left inside main tire almost needs replacement. 
Engineers: Almost replaced left inside main tire.

Pilot: Test flight OK, except auto-land very rough. 
Engineers: Auto-land not installed on this aircraft.

Pilot: Something loose in cockpit. 
Engineers: Something tightened in cockpit. 

Pilot: Dead bugs on windshield. 
Engineers: Live bugs on back-order. 

Pilot: Autopilot in altitude-hold mode produces a 200 feet per minute descent. 
Engineers: Cannot reproduce problem on ground. 

Pilot: Evidence of leak on right main landing gear. 
Engineers: Evidence removed. 

Pilot: DME volume unbelievably loud. 
Engineers: DME volume set to more believable level. 

Pilot: Friction locks cause throttle levers to stick. 
 Engineers: That's what friction locks are for. 

Pilot: IFF inoperative in OFF mode. 
Engineers: IFF always inoperative in OFF mode. 

Pilot: Suspected crack in windshield. 
Engineers: Suspect you're right. 

Pilot: Number 3 engine missing. 
Engineers: Engine found on right wing after brief search. 

Pilot: Aircraft handles funny. 
Engineers: Aircraft warned to straighten up, fly right, and be serious. 

Pilot: Target radar hums. 
Engineers: Reprogrammed target radar with lyrics. 

Pilot: Mouse in cockpit. 
Engineers: Cat installed. 

Pilot: Noise coming from under instrument panel. Sounds like a midget pounding on something with a hammer. 
Engineers: Took hammer away from midget.

Monday, 5 September 2011

A load of old Cobol...

Todd, Software Engineer at Objektum Solutions, discusses what he has learnt about the legacy language, Cobol... 

Having just started my career as a software engineer, I was only really peripherally aware of Cobol; my knowledge only extending so far as knowing that Cobol is a programing language and that it’s ‘quite old’. A quick search told me that Cobol is around 50 years old, which lead me to think that its use must be fairly small, probably only for a handful of mainframe applications or unimportant systems that aren’t worth migrating and probably haven’t been run for years or perhaps decades.

Now before you snort in (well deserved) derision, I’m more than happy to hold up my hands and admit that I was as ignorant as they come. Imagine my surprise then, when during the course of doing background research for the CobolExplorer I came across the following figures in an article about employability of Cobol developers

  • 70-75% of the business and transaction systems around the world run on COBOL
  • The average American still interacts with a COBOL program 13 times a day
  • 90% of global financial transactions are processed in COBOL

(Sources available at the foot of the linked article)

Even taking into account the age of some of the figures it was clear to me that there is a LOT of Cobol out there, much more than I would have imagined. This new revelation forced me to start wondering who exactly is maintaining all this code, and more importantly why?

A 2008 report by Forrester Research titled ‘Software and Services Data Overview’ shows that maintenance accounts for around a third of the total-cost-of-ownership of any piece of software. It isn’t obvious if that figure includes the cost associated with having to train people in the legacy systems well enough to continue maintaining/supporting them, but I’d hazard a guess that it doesn’t.

In our recent work here at the office we’ve seen first-hand that maintenance costs aren’t the only way that legacy systems can harm organisations ability to generate revenue.  How many potential wellsprings of profit have been left untapped because the current system wasn’t able to handle the required changes, or people qualified to carry out the work were unavailable? If you aren’t able to engage a new audience or expand into a new area it’s certain your competitors are more than happy to do so.

Automatic extraction and reporting of business rules directly from legacy Cobol source is just one of the ways CobolExplorer is able to help your organisation save time and money when estimating and tracking your legacy migration project.

Do you have legacy Cobol applications? Contact us today to arrange a discussion or webinar and find out more reasons that CobolExplorer is indispensable to your business.