OZONE Asylum
Forums
Mad Scientists' Laboratory
A faster forum using accurate modelling techniques
This page's ID:
27269
Search
QuickChanges
Forums
FAQ
Archives
Register
Edit Post
Who can edit a post?
The poster and administrators may edit a post. The poster can only edit it for a short while after the initial post.
Your User Name:
Your Password:
Login Options:
Remember Me On This Computer
Your Text:
Insert Slimies »
Insert UBB Code »
Close
Last Tag
|
All Tags
UBB Help
Grumble, don't get me wrong, but the first question, I have already answered and rephrased. Anyway, It would flesh out all possible uses of the Asylum. This alone allows spotting bugs. In the course of this, we'd have to define actors, which would also flesh out all fundamental elements of the Asylum. In other words, the resulting, and real-world oriented diagram would simply be the functional skeleton of the asylum summed up in a bunch of plain words, and a couple of arrows. Again, when the actors are "message", "thread", "forum" in the real world language... And when we know which attributes they have, and how they interact with each other... When we have the scenario, and draw the arrows that represent all the interactions... Then actors become objects, interactions become methods, and attributes become properties. Objects, methods, properties. <------------------------ re-read that 1000 times: actors => objects, interactions => methods, attributes => properties, A REAL WORLD SITUATION, DEPICTED IN SIMPLE WORDS, JUST HAS BECOME THE PLAN OF AN APPLICATION IN A TWIST OF HAND. An object oriented class diagram. Not ANY class diagram, an IDEAL way to map the real world scenario into an OOP diagram. I cannot emphasize enough on the word I-D-E-A-L, that's the crux, that's the true answer to your question: mapping real world to OOP this way makes the result excellent, and easy to improve without implementing a single line of code. Compare IDEAL to CURRENT, and you have your FLAWS outlined. And there you go with situations like "oooh, wait, we wanted that feature to work this way, but something's gone wrong in the actual implementation." Or "heeeeey... I can achieve this with less steps". Useless methods will disappear, intricated methods are shred into smaller/faster/more flexible bits, the general structure moves from "implemented with coding skills" to "implemented with a perfect plan". I can't explain it with other words, you have to try it out or I have to show you the next steps if you're not getting it. ... In a recent app of mine, I had a huge method called "drawHelix" I took from a Nehe tutorial. This awful thing basically drew a 3d helix on the fly, and radial blurred it using several passes, all in one method, all in a single main.cpp file. Having applied UML and reasoning to this Nehe thing, I now have a class called "filters", with a "drawblur" method. I have a class called "Object" which defines a template 3d object. And a class called ObjectFactory, which generates primitives. The result: 3d primitive is generated ONCE (as opposed to on-the-fly), which makes for a good 100% speed improvement, probably more, didn't benchmark. AND the blur can be applied to ANY primitive (as opposed to being stuck to the Helix thing). ---------------------------------------------------------------------------------- As an engineer in training by night, I have modelling courses all year long, it has lasted three years so far, and I have spent the last months working on four quality applications. Two with different teams, two on my own. I also deliver quality support services, in my job, to Philip Morris, and trust me, they like quality. :) I grant you a point though, for I have passed a heavy "IT processes (ITIL)" exam the other day, and it tends to make me see life in terms of "structures and relationships". ---------------------------------------------------------------------------------- Seriously, though. These things just work, I apply them day to day: how many times in my life did I completely rewrite a procedure? Or how many times did I throw one away because it had become irrelevant and useless as the application had grown? ALL this wasted time disappears with a solid plan: you're not "benchmarking two ways" and "implementing them" all the time, you have such a solid plan you can shift this or that detail and immediately see how it impacts the whole. ---------------------------------------------------------------------------------- Why else? Because it fucking makes life easier, applications faster and better, and I have a proven experience with it. And because I'd love to visually slap you with a huge trout right now. *Slaps Grumble silly with the trout of all trouts* [small](Edited by [url=http://www.ozoneasylum.com/user/5827]_Mauro[/url] on 01-06-2006 23:59)[/small]
Loading...
Options:
Enable Slimies
Enable Linkwords
« Backwards
—
Onwards »