Anyone knows where correct information on how a specific class diagram (in uml) is meant to be implemented? Like fx. how is an "association" to be coded? What about sterotypes? What are they actually? I looked at some generated code form CASE tools (rational rose and class builder) but the code is silly, horrible, and different in cases.

I can't remember much of the top of my head. As far as I remember stereotypes are the same as templates and the implementation of associations vary depending on the type. There can be Composition, Aggregation and a few more. Anyway, I am just finished my BSc in CS. First semester fourth year we had a module in this stuff. The lecture notes can be found at http://www.csis.ul.ie/Modules/CS4417/default.htm. They are a lot of cut and pasting from the main UML books out there (forgotten names now even!!). Hit lectures on the left of that page and then "lectures 13 - 24". I'd recommend readig 14 thru 19 for that type of stuff. NJoy John

UML, as it is a design and specification language is far more expressive than C++ ( Or indeed any programming language ). Translation from UML to an implementation language is not symetric, one specification maps to many potential implementations. And I agree, all the CASE tools I have seen produce crap code.

Thanks for the link, and for oarfish's point of view. Definitely good reading. I find some entities and behaviours i OO philosophy very hard to represent, like linked lists and neural networks. How is it possible (if at all) by using OO to take a top-down approach on such entity as Neural network? One could model a "Neuron" object, with synapsis as attributes and so on, but then what? How could the actual network (and parhaps their syns possible weights) be represented / designed? Any suggestion? These questions are to find the most appropiate methodology for game development, wich doesn't have to be object oriented. What methodology you recommend for game development?

Originally posted by Fabio What methodology you recommend for game development?

If you're looking for a "lightweight", flexible, yet disciplined methodology that helps you produce a very robust product, check out XP. It is geared towards object oriented programming, but not tied to it. I used it on a games localisation tool and it's the best code (and most reliable product) I've ever written. http://www.extremeprogramming.org http://www.xprogramming.com http://www.pairprogramming.com http://www.refactoring.com http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap The conversion of Tony Hawk's skateboarding to dreamcast contained some elements of XP. Check http://www.gamasutra.com/features/20000628a/fristrom_02.htm for details

How would you compare it to, say, OORP or OOA&D ? It looks like it has some elemenst from RAD and IE?

I haven't used said methodologies so I can't really compare. XP does have a reputation for being a lot less "heavy" than things like the Unified Software Development Process. Perhaps check "eXtreme Programming Explained" by Kent Beck, or the many XP pages for a history of it/comparison with other methodologies.

That "pair programming" seems interesting, is it any good?

Originally posted by Fabio That "pair programming" seems interesting, is it any good?

Absolutely. It seems odd at first, but you'll never go back once you've done it. It's effectively like having a code review 100% of the time that you code. Anytime I code on my own without my programming partner, I always make stupid mistakes which means I waste time later fixing them. With someone watching over you, your chances of mistake are drastically reduced. Probably the best thing ever is unit testing. There's nothing quite like seeing that you have 311 test cases all running at 100%. It completely changes your view of software. You suddenly realise that it is possible to release software that isn't bug-ridden. Also, refactoring is an excellent tool to have. Refactoring is like a roadmap to design patterns.

That seems too good to be true! But who will code, and who will watch? What about programmers at different levels? It it effective particular phase/stage? What I do with the suddenly 2x free machines? Won't a programmer feel like an "assistent" if he just sits and stare? Maybe they change places over time? What about if they disagree or have different ways of solving a problem? Won't the more restricted programmer be bound to always agree with the more talkee/argumented programmer? Parhaps, they will learn experience from each other over time? (too great ) Maybe I'm just too excited? Who invented it?

>But who will code, and who will watch? You take turns. You can decide when to switch around. For example, at the end of a particular task. Or if one of you is quite tired programming, you can switch around and let the other person "drive". >What about programmers at different levels? There was a survey of this on http://www.pairprogramming.com. The results should be out in a new book. Personally I think it works at all different levels. Everyone has something to learn. >It it effective particular phase/stage? Not sure what you mean?? Do you mean is it effective *at a* particular phase/stage? I don't think so. I think it's good at all stages of design/coding/testing/refactoring. >What I do with the suddenly 2x free machines? Well, you can still let people have their normal machines for their mail etc. It's best to put the development machines in a seperate area so that everyone is coding beside each other and can help each other. (Also, you don't get distracted by emails/phones etc..). >Won't a programmer feel like an "assistent" if he just sits and stare? You don't sit and stare. You contribute. You analyse every line of code looking for mistakes. You try to spot areas of the code where there is duplicate logic/refactoring to be done. You make decisions together. >Maybe they change places over time? Yep. See above. >What about if they disagree or have different ways of solving a problem? Well, you talk it out, weigh up both sides. If it's something that affects the customer, then you get input from your in-house customer. If it's an internal thing, you can get input from other programmers. If you still can't decide what the best coding solution is, then the chances are that both solutions are good. If you're wrong, you simply change it later (refactoring). XP has very definite coding guidelines (i.e. refactor mercilessly) >Won't the more restricted programmer be bound to always agree with the more talkee/argumented programmer? Hmm, perhaps. In that case, maybe it's best to pair the programmers with different people. The idea is that you switch people around every couple of weeks. That way knowledge is shared and it helps to reduce the need for the "expert". (Experts are bad) >Parhaps, they will learn experience from each other over time? (too great ) I think you'll always learn something regardless of your skill level - whether it's programming, or simply how to deal positively with different types of people. >Maybe I'm just too excited? Perhaps so >Who invented it? Not sure. It's been around for a while (70s) , but has been revitalised by XP. Again, see http://www.pairprogramming.com for more info on it. The hard part is convincing your manager.

I've been reading about XP for a while now, it's very interesting to hear from someone who's tried it. And clearly thinks it works. I'm intrigued.

I'm intrigued.

Why? I was pretty sceptical at first (some of the guys here at my job started mumbling about XP), but having heard a lot about it, I think it seems great. - Unit testing is fantastic, especially for component development - Pair programming might be a bit annoying, but is great for spotting bugs - Short development cycles are really good - I've been in too many 8 months+ projects where, at the end, nothing works. - Iterative development as a rule is pretty difficult to pull through without breaking external dependencies, but it sure sounds nice - "Everybody owns the code" is a really good concept, prevents the "Who's responsible?" effect. - No design, all coding. This is where I think they go to far... Since the development cycles are fairly short, it might work, but having designs on paper is actually a good thing, albeit hard to produce. There's nothing like it to match requirements against design ideas and actual implementation... It actually seems reasonable.

I'm intrigued cos I wonder if I ought to be looking for a project that uses it when looking for my next job (in about 8 months time). I'm truly hacked off with having no design process, OTOH I don't want to work with a heavyweight methodology that chokes the interesting side out of my job.

- Unit testing is fantastic, especially for component development

Kim, what form do these tests take? I find it hard to imagine a complete test suite for some of the complex objects we currently work with in our game. Cheers Matt

> I'm truly hacked off My English is insufficient - what does this mean? About unit testing: I felt the same way... I've been building a reasonably complex security system (access control a'la NT, grouping, session management) and didn't know about unit testing till I was finished, so I've used it to make sure I maintain backwards compatibility - I wrote a universal test before starting on a new version, and was then able to verify that it still worked after I was finished. XP apparently advocates something called mock objects to make tests easier and to loosen dependencies between teams. They are just stand-ins, that implement the interface required, but do as little as possible - basically just return valid data. That way, you can really unit-test class by class, building all dependecies on mock-ups. It sort of forces a good non-coupled design as well... Sounds like a lot of work though, unless you can test smaller parts separately. I'm not all that much into XP, but some of my colleagues are lost, so they keep trying to convince me

I don't know, this all seems so bloody obvious that I'm surprised it took people so long to figure it out. I mean, if you make an OOP design what's more logical than making the framework first with dummy objects, and then filling it out with the real code? And if possible prove things as well, but I guess engineers hate the word prove (and admittedly it's not a trivial thing in the real world).

this all seems so bloody obvious that I'm surprised it took people so long to figure it out

It does, doesn't it? The thing is, most parts of XP are things you're doing already without really thinking (unit testing, pair programming, iterative development). It's just semi-formalized, and brought together.