Methods

The In 1983 Universities in England were teaching DeMarco, Yourdon and Ward/ Mellor methodologies as part of the software engineering foundation. Prior to that, colleges and schools had been teaching the well known stepwise refinement and pseudo code. As companies began to see the importance of having a solid understanding about its software more focus was placed on the data with respect to relationships. Certainly this still remains strong to the present day with Oracle’s entity relationship diagrams. Companies like Cadre and Software Thru Pictures allowed software developers to practice and refine various partitioning and levelling techniques.

Industry also took note awarding companies that did follow a method with future work. Gone were the days when geeks could just muster up a fag packet design down the pub and put it into practice.

Other designers wanted to diverge methods as in some instances DeMarco, Yourdon and Ward/ Mellor did not cater for the whole fraternity. Also Yourdon tended not to work particularly well as you would end up with a football pitch of a system which would prove difficult to partition up (there was not enough abstraction in the method to allow translation), these designers were the forbearers of UML namely Booch, Jacobson, Rumbaugh, Selic, Gullekson and Ward added to the list. Clearly the Department of Defense of America was getting worried and wanted to standardize the process of Software Engineering in a sense that system requirements could be traceable. In 1988, the DOD 2167a standard was introduced for DOD contracts. It debued a fanfare and was righteously congratulated. Essentially it was formed to ensure that projects could be assessed to see if budgets were going to be met (time and cost); and broken down into various components. Most industries however did not want to conform to both 2167a and modelling. Certainly different departments in software houses had different methods and practices. Database modelling prefers more structure in the way data is interpreted, where as real time processes prefer more functional orientated methods.

The DOD 2167a standard, good as though it was, was too rigid in its waterfall effect and could not take into account of the software development iterative cycle of today’s projects. Also DOD 2167a projects had to have budgets that had to be met; it was very rare to find prototyping being done.

• there weren’t any RAD tools around,
• the people that would do the prototyping were senior engineers already wrapped up in the designs of 2167a solution
  (a shared resource) .

So realistically DOD 2167a projects took longer to complete and to amend. As projects extended more DOD and MOD contracts were awarded as ‘fixed price’, so the onus was to meet budget. For instance, engineers of today would not want to use Interleaf to view and amend DOD 2167a documentation as they could be prototyping or modelling.

Fortunately with all the divergence of software development tools saw the generalization and conception of UML (Unified Modelling Language) through the Object Management Group. Oddly enough this came on board at the same time C++ caught on. UML was urgently needed for C++ as C++ bore reliability issues that had to be addressed if businesses were going to use multiple inheritance and object orientated systems.

Microsoft’s developments with Visual Studio proved to be a resounding success and provided businesses with exactly the type of ‘Studio’ it needed. Oddly enough it is usually the military which develops new technology which eventually is fed back into the commercial sector in one form or another. This time around, the commercial software development sector were ahead. In real time programming developments, visual studio took time to establish itself due to operating system reliability. This was rectified with the introduction of Windows 2000 Server. Up to then it was always preferred to be a Real Time OS such as the likes RTM, MPX, RMX and Unix (to name but a few).

The USA’s DOD wanted to stay clear of the reliability issues associated with multiple inheritance the loose pointer typing of C++. Certainly with more and more embedded systems being created there didn’t want to be the occasion of a system failure of a primary aerospace black box. Ada was developed and used in Real time systems. Ada is more than a language:-

• It is a programmers environment,
• It has only one level of inheritance 
• is strongly typed and
• is object orientated (supporting instantiation, overriding and polymorphism and encapsulation).

Ada is the preferred language for development in satellite and embedded design. Initially, there were different Ada95 compilers around which then saw the introduction of GNAT’s Ada9x, which is the standard adopted for today. Interestingly this brought in extra requirements for UML as it introduced Rendevous and Balk message handling facilities. Signalling had to be introduced into the UML standard.

There are lots of different vendors on the market. One of the best UML tools for real time and embedded systems is Rhapsody from iLogix. With this developers can go all the way and generate code (in Ada and C++ and more). Visual Paradigm is another modelling tool, it is a great starter and allows learners to become intermediates in next to no time. Indeed there are many different vendors.

Going back to DOD 2167a, the founder has always stipulated that 2167a was just an initial standard to support the development of systems. Hence the a revision and could have been changed to support iteration.

Another DOD standard which supported iteration development is DO 178b which is currently being used in the Aerospace Industry. Very similar  to 2167a. There is more emphasis on verification procedures and certain type of failure handling as well as dealing with iterative/cyclic developments.

A very highly recommended book for modelling techniques goes to Bruce Powel Douglas with his  “Real-Time UML Second Edition Developing Efficient Objects for Embedded Systems “ ISBN 0-2015-6784-8
Many a meeting has been had with the programming team all trying to fight out the best way of representing a model. With his precise views using ROPES it is possible to reduce the fight into an ordily discussion around a table and translate a model into a working system in next to no time.