My First Company Tool

This week our trainee software engineer Joe has made/developed his first tool that will be used by Objektum at a customer site. He tells us about his experience.

The tool that I have written is called the FileCopier; its primary functions are to take a list of file names and search a directory and all the sub-directories within for each file in the list. Once it has found the file it then copies it to an output destination, selected by the user.

The Problem

The initial idea of the tool was simple, find a file within a nested directory structure and copy it to another directory. It was time to turn this idea into a tool. I started out by creating a simple form that would allow the user to select a file which contained a list of file names that were going to be searched for, select the directory that was going to be searched and then where the documents were going to be copied to.

The code behind the form

This was my first pressured programming experience, the deadline was very close and I didn’t have much of an idea of where to start. Getting all the buttons on the form to work seemed like a good start, and after a few initial hiccups with trying to select a directory in VB6 that will be searched, I was able to find a working solution for all the button click events.

The next part was the one that I thought I was going to struggle with; recursively searching for the file in each directory and its sub-directories. After a couple of hours of writing pseudo code and working with the VB6 file IO libraries I finally found an elegant solution. With the help of Derek and Todd I was able to implement the code that made it possible for the files to be searched and copied to the target directory.

I thought that was the tool complete but we still had some small bugs in the code. It was then time to run through and pick through every small detail and make sure that it was functioning correctly. The first problem we found was that the tool was still continuing to search after it had found the file, because we didn’t tell the program to exit and search for the next file in the list as soon as it had found the one matching the file name. Tracking down the problem was the hard part, but the fix was fairly easy once we had found it.

After a few more small changes I had created my first tool for Objektum Modernization. After tidying up the form it was ready for use.

The thought that I would have made a tool that will be used by a customer within the first year of starting my programming experience was something that hadn’t even come to mind. It made me realise that I am making good progress and I just need to keep practising and learning and it will not be long till I can contribute a lot more than just a simple tool to the company.

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.

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!  

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! 

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.

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...

The Truth of Motivation

Here's a video that we've been watching at Objektum Solutions HQ about motivation. We all found it fascinating (and fun to watch) and so we thought we'd share it with you. So, spare a little time to find out the truth about motivation...

 

Software

Copyright 2010 gapingvoid gallery

This is an image drawn by Hugh MacLeod of Gaping Void depicting his experience of software, what's yours?

Camtasia Studio top tips for Software Demos

Fiona has been busy putting together software demonstrations for our Legacy Bridge Technology and shares her top tips on using Camtasia....

Camtasia Studio is the first video editing software I’ve ever experienced, thus my knowledge of video editing was previously limited and restricted.  Initially it was an overwhelming task to gain a full understanding of the software and to manufacture a video which looked and sounded flawless. However, Camtasia is designed in a way which allows the user to complete sophisticated and involved tasks with ease of navigation and expertise. 

My experience of Camtasia has increased significantly after hours of scrupulous editing and re-editing and I have been able to create a polished and professional demo video and presentation video. Hence, I have pieced together a few handy tips which may be useful to somebody who is evaluating the available video editing packages or has decided upon Camtasia Studio for their video production.

Before recording commences there are certain considerations which need to be well thought-out. For example, there’s nothing more frustrating than to be in the midst of a perfect recording only to be interrupted by a phone ringing in the background or an email notification suddenly appearing on the screen.  A contingency plan can be devised prior to recording to avoid this situation. Ensure the recording takes place in a quiet, out-of-the-way room. Also make certain all applications are closed except those specifically needed for the recording; in particular all email accounts should be closed. 

With regards to editing here are a couple of time-saving tips. Adjust the select area dimensions before recording the screen; this will skirt painstaking editing after recording is complete. In the same vein, when recording a presentation video use the cursor liberally and then remove the cursor visibility in the editing process by deselecting mouse cursor visible. It is also possible to achieve the reverse effect and emphasise the cursor by adding a highlight effect. 

A handy hint to make a demonstration video more interesting and dynamic is to add callouts which are ready made shapes such as an arrow, which can be used to visually communicate information and will engage viewer’s attention. Zoom levels are another way to visually convey a message to the viewer. It is possible to zoom and pan to the specific areas of the screen being discussed in the audio adding clarity and understanding to the communication.

Finally, once a recording has been edited and is ready for production, select custom production settings, this will allow variation in the file format for the production of the final video. The file formats available range from avi to mp4. 

All it remains to say is, happy recording!

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.

.

Avionics and Defence Electronics Europe 2011

Just a quick piece copied across from our News to let you all know that we'll be in Munich, Germany very soon! 

  

After a strategic move to relocate the show to Munich, Avionics Europe 2011 is looking set to be a good show. We’re particularly looking forward to meeting our industry peers at the exhibition as well meeting some new people! The conference looks like it will impress and we’ll definitely be heading to hear the Managing Obsolescence talk as this is something we have been spending a lot of time working on through our Legacy Bridge Suite which can enable projects and organisations to automatically move away from legacy systems into more modern methodologies such as UML.

 Our Technical Director Derek Russell will be making an appearance and discussing How to Manage Obsolescence using Technology in the Exhibitor Presentation area, times to be confirmed. He will be taking a look at how a large defence company used automatic migration to move from HOOD and Ada 83 to UML and Ada 95 whilst mitigating risk, protecting financial investment and protecting design integrity.

We’re based on Stand C5 right next to the Exhibitor Presentation space where will be doing demos of the Legacy Bridge Suite technology. It has been described by clients as “wizardry”, “the most innovative piece of technology they have seen in a long time” and one client has even said “It’s like all my dreams have come true”. So come to our stand and see it for yourself!

We’ve also grown our training business and have a multitude of new courses including Systems Engineering using MatLab and a range of MoDAF courses. We have also introduced a range of Personal Development courses due to popular demand. These courses set out to support teams to work more effectively and are adapted to deal specifically with people working in our industry.

Visit Stand C5  to chat to either Derek Russell or Ajay Patel. If you would like to set up a meeting with either of them please contact us. 

----------------------------------

About the Show

AVIONICS EUROPE

Avionics Europe is the premier platform for discussing commercial and defence related avionics issues in Europe; bringing together the most influential and high-ranking members from the market and has become the ‘must attend’ event on the Avionics calendar.

Avionics Expo allows key decision makers, scientists, technologists, engineers and procurement specialists from within the leading avionics manufacturers, suppliers, integrators, airlines, operators and air-framers, prime contractors and end users to discover and discuss the latest issues and developments affecting avionics technology.

DEFENCE ELECTRONICS

Defence Electronics aims to provide a unique platform for defence electronics industry, including systems, components and services covering land, air and sea based systems.

Senior level project leaders/directors and senior engineers involved in mission systems, planning, design and specifications from prime contractors and system integrators.

In addition visitors would be from the leading builders and framers of vehicle and mobile communication systems and end users such as international defence agencies, departments or ministries of defence, dignitaries and officers from the armed forces who have influence and purchasing decisions.