Sunday, October 23, 2005
SAD
I've just finished the structured analysis and design course my employer sent me on. It was based on UML 2.0 of course and actually wasn't too bad. The instructor (John Conolly) seemed to actually be competent, which was a nice surprise.
My only worry is that this kind of activity won't actually resolve any of the issues we tend to have to deal with when developing software in the commercial world, namely that 'the business' never knows what it actually wants (and even more rarely what it needs) and the developers are never given enough time to write even half-decent code (in our case in Java). Whilst structured analysis / design should help I just can't see us getting the time to do the job properly unfortunately.
UML doesn't look like it will fit in too well with Lisp, but I was expecting that. I suspect with a few tweaks (support for multimethods being the most obvious) UML could be used to represent a Lisp system. Unfortunately dabbling in structured design will pretty much destroy one of the biggest strengths of Lisp; namely the dynamic nature of development and the ability to change running code on the fly.
I think it shouldn't be too hard to dump the structure of a Lisp program into UML though (well - once the limitations of UML wrt Lisp are addressed) so in terms of 'model driven architecture' Lisp and UML should be a pretty good match.
The 3-week course has halted the work I was doing porting DUIM into Lisp. I'll get back to that over the next couple of days. Most of the Dylan code has been converted now, but I need to finish off the macros (Dylan's macro syntax feels very kludgy compared to Lisp's) but that shouldn't take too long. There are a few compatability methods I want to revisit and I'm going to wrap Lisp sequences to make them look more like their Dylan counterparts.
I've also got quite a big job to do documenting the thing (Fundev's documentation is good but I want more detail; think CLIM 2 spec rather than DUIM API reference) and writing some automated tests.
My only worry is that this kind of activity won't actually resolve any of the issues we tend to have to deal with when developing software in the commercial world, namely that 'the business' never knows what it actually wants (and even more rarely what it needs) and the developers are never given enough time to write even half-decent code (in our case in Java). Whilst structured analysis / design should help I just can't see us getting the time to do the job properly unfortunately.
UML doesn't look like it will fit in too well with Lisp, but I was expecting that. I suspect with a few tweaks (support for multimethods being the most obvious) UML could be used to represent a Lisp system. Unfortunately dabbling in structured design will pretty much destroy one of the biggest strengths of Lisp; namely the dynamic nature of development and the ability to change running code on the fly.
I think it shouldn't be too hard to dump the structure of a Lisp program into UML though (well - once the limitations of UML wrt Lisp are addressed) so in terms of 'model driven architecture' Lisp and UML should be a pretty good match.
The 3-week course has halted the work I was doing porting DUIM into Lisp. I'll get back to that over the next couple of days. Most of the Dylan code has been converted now, but I need to finish off the macros (Dylan's macro syntax feels very kludgy compared to Lisp's) but that shouldn't take too long. There are a few compatability methods I want to revisit and I'm going to wrap Lisp sequences to make them look more like their Dylan counterparts.
I've also got quite a big job to do documenting the thing (Fundev's documentation is good but I want more detail; think CLIM 2 spec rather than DUIM API reference) and writing some automated tests.
# posted by Duncan Rose @ 1:44 am 
