Home » Stars! Clones, Extensions, Modding » FreeStars » Design (Class Diagrams, etc)
| Design (Class Diagrams, etc) |
Sun, 12 February 2006 21:55  |
|
 Zoiker |
 | Petty Officer 2nd Class |
Messages: 59
Registered: January 2006 | |
|
I seem to recall seeing a UML class diagram that showed part of the design for one of the open source projects. Are there any others? I'd be interesed in seeing how folks are approaching it.
Cheers,
Zoiker
Report message to a moderator
|
|
|
| | | |
| Re: Design (Class Diagrams, etc) |
Wed, 15 February 2006 15:40  |
|
| Madman |
 | Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
| Zoiker wrote on Thu, 16 February 2006 09:22 |
Development projects typically work better when design is done before development. It also makes it a lot easier for multiple developers to participate.
|
Well, I think what Kotk is referring to is that Freestars is a done by a group of volunteers who are doing it for fun or because we want to, and as such UML diagrams are not high on the agenda.
Pay me $40 an hour to work on FreeStars and you'll get as many UML diagrams as you want, until then I'll work on bits that I'm interested in.
Actually, class diagrams are somewhat less necessary than usual for this project anyway - most of the entities are things like Planet, Ships, Fleet etc. which have fairly obvious relationships. This project is hardly rocket science.
Are you making an offer to contribute such diagrams, Zoiker?
Report message to a moderator
|
|
|
|
| Re: Design (Class Diagrams, etc) |
Wed, 15 February 2006 17:45 |
|
| Kotk | 
 | Commander |
Messages: 1227
Registered: May 2003 | |
|
| Zoiker wrote on Wed, 15 February 2006 22:22 |
I'm clearly not getting your sense of humor, Kotk. 
|
You did not understand what made me laugh?  I am terribly sorry if you werent, but it sounded like you were just joking.
It was very funny.  Imagine my boss comes in and say "Some other programmers seem to have UML diagrams. So ... where are your UML diagrams?". OK, so i shrug him away that check the docs. There are some docs and prototypes (like agreed), but no UML diagrams. Then few hours later i hear that "hmm, you do wrong things without UML diagrams there, no wonder you suck bad". If i had this sort of rude boss, i likely would quit. However if someone (i dont have any relations with you) jumps out of nowhere and roleplays such a boss ... then how it ... isnt funny? 
Will you sit down with us and make what you think is right and cool thing to make (UML)? 
Report message to a moderator
|
|
|
|
| Re: Design (Class Diagrams, etc) |
Wed, 15 February 2006 18:41 |
|
| Zoiker |
| Petty Officer 2nd Class |
Messages: 59
Registered: January 2006 | |
|
| Madman wrote on Wed, 15 February 2006 15:40 |
Actually, class diagrams are somewhat less necessary than usual for this project anyway - most of the entities are things like Planet, Ships, Fleet etc. which have fairly obvious relationships. This project is hardly rocket science.
Are you making an offer to contribute such diagrams, Zoiker?
|
I sense you are not alone with that assessment.
If all you had to do was code up these objects then you're right, writing class diagrams isn't going to add a lot of value. But class diagrams aren't about the data being stored, they are about the behaviors of those objects and how they interact.
The Jeffs wrote Stars! using a procedural mindset, and they would be the first to admit how painful it was to maintain and enhance. A good OO design encapsulates behaviors and, while it takes a little more time up front to design, is a heck of a lot easier to code, maintain and enhance.
I did see one class diagram from one of the Stars open source projects and it was clearly written by a procedural coder. Massive objects with absolutely zero decoupling, which means it's very hard to divvy up work and will be a nightmare to maintain.
Jeff McBride alluded to this in a HWF article a while back, and I think his example was the different behaviors of various components. A Croby Sharmor 'shield' has the same attributes of any other component (mineral and resource cost, tech requirements, etc) but it also has abilities of two different component types - shield and armor. Here's a great example where you can use good OO techniques to decouple and re-use those behaviors. The Strategy design pattern might be a good fit, here.
I've often thought of developing the class and sequence diagrams for this game, more as an exercise than any step towards actually writing it, and I suppose if there were folks out there willing to engage in a spirited discussion about it, it might be worthwhile.
For now, I'll go out on a limb and stir it up and submit that had proper design been done up front, we would likely be playing some of these Stars clones by now. 
Let the flames begin! 
Cheers,
Zoiker
Report message to a moderator
|
|
|
|
| Re: Design (Class Diagrams, etc) |
Wed, 15 February 2006 18:48 |
|
| Zoiker |
| Petty Officer 2nd Class |
Messages: 59
Registered: January 2006 | |
|
| Kotk wrote on Wed, 15 February 2006 17:45 |
I am terribly sorry if you werent, but it sounded like you were just joking.
It was very funny.
|
Well, if you put it that way...
I can see the humor in it. But I was being serious. Trying to code without a design on anything more than a trivial project often results in projects being late. If one of my developers said this is so easy I don't need a class diagram, I'd suggest writing a class diagram wouldn't take much time then.
It sounds as though we have some programmers out here...what do ya'll program in? C++, Java, C#, etc?
Cheers,
Zoiker
Report message to a moderator
|
|
|
| | |
| Re: Design (Class Diagrams, etc) |
Wed, 15 February 2006 22:09 |
|
| Zoiker |
| Petty Officer 2nd Class |
Messages: 59
Registered: January 2006 | |
|
| LEit wrote on Wed, 15 February 2006 21:53 |
The basic spec is Stars! itself (and lots of analysis that people have done).
|
Agreed - that's one of the great things about a refactoring project such as this; we already know the domain inside and out so requirements analysis is already done.
| Quote: |
I'm not sure which diagrams you've seen, there was one some one put together from the FreeStars code. The objects are big because there is a lot of data needed to describe them.
|
I don't recall which one I saw - it's been a while - and a cursory search didn't uncover it. What I do recall was a lot of primitives being used to store information. Primitives have their advantages, of course, but they tend to tightly couple the design, which makes enhancements really hard. The common thread between all of the Stars projects is that most folks want to build something that's just like Stars as Phase I, then extend it to do all kinds of cool things in Phase II. A great approach, IMHO, and a loosely coupled design would greatly facilitate that.
| Quote: |
Perhaps a design would help, if you (or anyone else) is willing to work on it, I would be willing to help a little. But I know I won't have the patience to do a full design. I've also seen too much time spent on designing things and then have the project fail because too much time was spent before anything tangible is developed.
|
Ain't that the truth. I've been involved in projects like this, too, and it's very demotivating. One of the nice things about the Stars projects going on is the use of iteration; it seems as though concrete chunks are being built so folks (like me) can see things as they progress. Ideally, good design and iterative development wouldn't be mutually exclusive.
I'd be up for spending some time on this. I'm fine with you (or others) not being able to spend time on it, so long as you're willing to give me your feedback.
Cheers,
Zoiker
Report message to a moderator
|
|
|
|
| Re: Design (Class Diagrams, etc) |
Fri, 17 February 2006 11:35 |
|
|
|
Hi!
Just my 
| Zoiker wrote on Thu, 16 February 2006 01:48 |
I can see the humor in it. But I was being serious. Trying to code without a design on anything more than a trivial project often results in projects being late. If one of my developers said this is so easy I don't need a class diagram, I'd suggest writing a class diagram wouldn't take much time then.
|
Well, the most funny thing in this is that we all play Stars! a lot and probably intuitively already "feel" a lot about how it could be built "inside" Creating diagrams in such case would be almost useless, IMO.
Another point is that here we have much like reverse-engineering, where you have working etalon program and need to create code for at least similar one. I barely imagine UML for such a case
Once it would come to adding new "big" features, UML might be useful, but still not that much.
If you would ever start somthing like Supernova, schedule UML for it for sure. UML is good for really large projects only, smaller ones may well go without it.
WBR, Vlad
Report message to a moderator
|
|
|
|
| Re: Design (Class Diagrams, etc) |
Fri, 17 February 2006 13:05 |
|
| Zoiker |
| Petty Officer 2nd Class |
Messages: 59
Registered: January 2006 | |
|
| Tomasoid wrote on Fri, 17 February 2006 11:35 |
Well, the most funny thing in this is that we all play Stars! a lot and probably intuitively already "feel" a lot about how it could be built "inside" Creating diagrams in such case would be almost useless, IMO.
|
Good point - because we've all played this so much we all have a very similar idea as to what the design would look like from a domain perspective. For example, we all know a ship design contains multiple ship slots, each of which can hold a specific number of components of certain types, etc.
I would still submit building this diagram (wouldn't take long) would be beneficial, especially considering the disparate involvement of folks with varying experience. But I also agree it's not that valuable.
What becomes valuable is decoupling the design by adding objects (abstract classes, interfaces, etc) that make the design more extendable. While we all have similar ideas about the domain objects, I think we might come up with different ways to design to interfaces and such. If we look at a planet's production queue, we can easily decouple its implementation from the things it builds by having this object contain a collection of IBuildable interfaces. Anything that needs to be build (planetary installations, ship designs, etc) simply have to implement the IBuildable interface (GetCost() is the primary method here).
To explain all this in text or code takes a little while to read, yet by looking at the diagram the design is immediately recognisable. I'll try my luck uploading an image so you can see.
http://photos1.blogger.com/blogger/7747/1815/1600/ProdQueueC lassDiagram.jpg
| Quote: |
UML is good for really large projects only, smaller ones may well go without it
|
I think in general that's a common belief, and for smaller projects I would submit that it's a personal choice. My development tool has UML with reverse-engineering built in, so even if I did just start coding, with the click of the mouse I can see the class diagram for it. My point being, I'm willing to submit I'm biased towards creating class diagrams because it takes little work on my part
What I think it comes down to is the definition of small. To be sure, Stars is not a hugely complex application and pales in comparison to a massive ERP application like Customer Relationship Management or something. But if it truly was small, someone could surely have completed a Stars clone by now.
Cheers,
Zoiker
Report message to a moderator
|
|
|
|
Goto Forum:
Current Time: Fri May 03 19:56:14 EDT 2024
|
Members
Search
Help
Register
Login
Home
