Editorial: Maximising the Re-use of Code
Reusing code sounds easy, after all we all have masses of utility functions which we copy into a CLEAR WS before starting development of a new system. But getting the maximum reuse is quite difficult, and requires some clever design work. At the last meeting Adrian Smith explained the techniques that help him to get towards a target of only having to write 20% of the code that is required for a system. He uses layers of building bricks which can be assembled to create the final result.
The lowest level of building brick seems to be relatively easy to define, and the majority of code published in Vector falls into this category. Ensuring portability across different varieties of APL also helps to define functions. Each APL vendor has had his own ideas of how to solve a common problem, and one can build on the various design solutions that have been devised. In fact, it really is essential to have basic building blocks to mask the detailed differences in APL interpreters.
Adrian identified a middle range of functions where he uses established designs such as SQL and PostScript as the basis of writing higher level code which can be reused in many situations. Design is much more difficult at this level, and picking up existing ideas, which are familiar to a wide audience, seems a very sensible thing to do.
Identifying common areas which can share code at the top level of a system is the most difficult thing to do. When a big system is being implemented with a team of analysts and programmers, then the problems multiply. Identifying common processes amongst the members of the team needs a clear and simple way of communicating design ideas.
One of the current solutions that is becoming popular is Object Oriented Analysis (OOA). Everything seems to be Object Oriented nowadays, so I suppose that it was inevitable that the term was applied to an analysis technique. OOA seems quite similar to Entity Analysis, as it helps to describe the data requirements and the processes needed to manipulate the data. The general ideas have been about for a long time and the OO tag has been added quite recently.
OOA is not to be confused with Object Oriented Design, or Object Oriented Languages, or Object Oriented x where x can be any word other than Analysis. On the surface OOA seems to me to be intuitive and reasonably easy to use. The fiendish detail required to do a proper job is quite difficult and requires practice, as is so often the case with something that is conceptually simple.
There is no problem using OOA for analysis for APL systems, as it does not depend on any particular language, and you don’t have to use Smalltalk or C++. I have seen several APL systems that could have benefited from a bit of formal design work before the developer plunged in and started hacking out code. Prototyping is all very well, but it can become an excuse for doing no design at all! Just carrying out some formal analysis seems to be a major benefit as it forces the clarification of exactly what is required. One of the advantages of OOA seems to be that the end of the analysis stage is well defined, so one does not have the temptation to carry on refining the design until it is ever more perfect.
OOA can go down to quite low levels, so that it would be possible to identify every APL function that is required for a system. However, I found the link between the final result and the implementation to be somewhat vague in the textbooks. This is possibly a price to be paid for a technique which is independent of the programming language to be used.
For those who have not already used analysis techniques, I would recommend that they look at OOA to see if it could help reduce the time taken to write systems. APL is fast, but with good designs, with a maximum reuse of code, it can go at GTi speeds!
(webpage generated: 21 April 2006, 00:47)