Max(cost): buy a new scanner/printer

Post #201,578 by FuManChu 4/1/05 2:01:59 PM Reply	Max(cost): buy a new scanner/printer 1. Draw the model on paper. 2. Scan the paper models. 3. Print the scanned images. Only let your boss see step 3.
Post #201,582 by jake123 4/1/05 2:35:07 PM Reply	I like it:) --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Kingston Ontario Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n-------------------------------------------------------------------
Post #201,593 by systems 4/1/05 4:52:00 PM Reply	Re: Max(cost): buy a new scanner/printer Actually, this isnt very practical, one of the classic virtues of using a word processor or the tradtional mechanical typewriter, is how easy it is to correct mistakes. Drawing a model is hard this is why i argued for an XML representation, write its in xml, see it as a picture, using a mouse to draw a model, is not very funny TCM is particularly terrible in this point Anyway, a model will 1,000,000% evolve over time, and text code enjoys programs like vim, esclipse, and emacs to facilitate cut'n'paste and moving around etc... Modeling need even more sophisticated tools for editing, not much work done here, drag'n'drop still rule, and its terrible Actually, more modeling should lead to less code refactoring So do refactor ur model as much as it needs, dont go cheap, with less sophisticated editing tools, no one would dare changing a model, ppl will keep a model as is, just so that dont refactore it Which is a terrible reason ... ORM kinda shines in this points, its designed intentionaly to be easier to extend than a traditional ERD (as in add more content to an existing diagram, not extent the languages itself) Pencil and papers models, are usually throw away models, and u dont wonna do that, models, should outlive code, if they dont, you are completely missing the point
Post #201,595 by jake123 4/1/05 5:06:38 PM Reply	I'd suggest using uml unified modelling language, seeing as it's actually designed for the task at hand, as opposed to xml, which isn't. That said, you should go through a pencil and paper phase first, as it's even easier to apply an eraser when one wants to see the effects of a model change than it is to change an xml (or even a uml) representation. --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Kingston Ontario Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n-------------------------------------------------------------------
Post #201,597 by systems 4/1/05 5:19:06 PM Reply	Re: I'd suggest using uml XML is not a subtitute for UML, I meant to write a model using XML, instead of a graphical editor using drag'n'drop Actually UML have a standard XML representation called XMI I think Writing a model in xml, instead of a graphical editor can be compared to designing a webpage in html as opposed to a wysiwig editors This is what I want, and havent found I dont want or like to draw diagrams by hand at all, its akward and clumsy
Post #201,599 by Arkadiy 4/1/05 5:32:06 PM Reply	What exactly do you mean by "model" here? -- "Consider a perfectly spherical cow, radiating milk isotropically." -- [link\|http://itre.cis.upenn.edu/~myl/languagelog/archives/002008.html\|Language Log]
Post #201,600 by systems 4/1/05 5:51:29 PM 4/1/05 5:51:59 PM Reply	Re: What exactly do you mean by "model" here? A model is an abstract representation of a system or a solution, being abstract it hides most or all the irelevant details For most ppl, a model = a diagram I was told, but I have no clue how, that u can express a model in other ways. But mainly i just had diagrams in mind, when i was speaking. a set of diagram notations that complement each other, is also usually refered to as a modeling language, like UML, or ORM or EERD Again I wanna exploit the moment, to say how much I like ORM [link\|http://www.orm.net\|http://www.orm.net] Edited by systems April 1, 2005, 05:51:59 PM EST Expand All History
Post #201,604 by Arkadiy 4/1/05 6:13:09 PM Reply	If you want to have a diagram, XML defeats the whole purpose - to engage the space-oriented part of your brain. If you don't care for diagrams, I'd use pseudocode. I fail to see how XML is appropriate in Modeling in your sense at all. -- "Consider a perfectly spherical cow, radiating milk isotropically." -- [link\|http://itre.cis.upenn.edu/~myl/languagelog/archives/002008.html\|Language Log]
Post #201,618 by drewk 4/1/05 11:14:39 PM Reply	Low-tech approach Start [link\|http://c2.com/cgi/wiki?CrcCard\|here]. Then start going through [link\|http://www.google.com/search?q=crc%2bsession%2bsite%3ac2.com\|this]. In particular [link\|http://c2.com/cgi/wiki?OnePieceOfPaper\|this] and [link\|http://c2.com/cgi/wiki?UmlDoesntWork\|this] and [link\|http://c2.com/cgi/wiki?HotDraw\|this]. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #201,623 by dws 4/2/05 12:07:15 AM Reply	Re: Low-tech approach I've used (or have tried to use) ArgoUML, but always seem to fall back on some combination of a whiteboard, 4x6 cards, some decent markers and pens, a camera, a scanner, and a wiki.
Post #201,658 by jake123 4/2/05 2:43:31 PM Reply	UML's good for docs But if you've got everything and the kitchen sink in your diagram (ie- all 1500 classes) then you're not using it properly. You've got to approach something like that in a layered perspective. For example, a client server application's top level uml diagram should have two or maybe three things on it; a client and the server, with the calls happening between them, and perhaps the actual network between them. Then, you can get the top level diagram for each of those two subsystems, keeping it simple throughout, breaking things down into subsystems as needed. You might also want to create a diagram representing the actual network between them if you have to deal with the particularities of the infrastructure architecture for your app, so that if you need to detail failover options at the network level you can do it in that specific diagram. Having it all in one diagram might make for a neat pic, but it's not very useful. The point of it is to help communicate the architecture of the application to other people, and a spaghetti diagram isn't going to do a very good job of that. --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Kingston Ontario Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n-------------------------------------------------------------------
Post #201,825 by Arkadiy 4/4/05 11:50:29 AM Reply	UML is good at showing you where you screwed up In my experience, if the design cannot be expressed as a neat simple diagram, I am doing something wrong. -- "Consider a perfectly spherical cow, radiating milk isotropically." -- [link\|http://itre.cis.upenn.edu/~myl/languagelog/archives/002008.html\|Language Log]
Post #201,874 by jake123 4/4/05 4:43:52 PM Reply	I can see how that goes I have to admit, I hadn't thought of it that way, but I can see why it would be good at showing those up. Related to the relative levels of experience betwixt you and I, methinks. --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Kingston Ontario Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n-------------------------------------------------------------------
Post #201,601 by jake123 4/1/05 6:01:03 PM 4/1/05 6:20:22 PM Reply	I'm not sure just what uml has to do with using 'drag and drop' to create a model. When I was taking the apps course last year, we had to model our applications in uml as an early phase of development. There were tools to do so, but in general I found it faster and easier to just hack out the text definitions anyway in raw uml. The L stands for Language, and it is in fact a language for creating models, including object models, app module models, or even ER models, let alone using it to model data flow or calls. I don't see what XML is going to get you except more verbosity. Edit: that said, I still agree with Peter that pencil and paper are the right first step; uml comes second, and that only if you have other developers on the project with whom you need to communicate protocols and specifications. --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Kingston Ontario Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n------------------------------------------------------------------- Edited by jake123 April 1, 2005, 06:20:22 PM EST Expand All History
Post #201,603 by admin 4/1/05 6:12:29 PM Reply	Models are only as good as their specs Most specifications are crap. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #201,667 by CRConrad 4/2/05 4:08:16 PM Reply	Holy... In response to Brewski Bob's: Max(cost): buy a new scanner/printer 1. Draw the model on paper. 2. Scan the paper models. 3. Print the scanned images. Only let your boss see step 3. this little "systems" weirdo writes: Actually, this isnt very practical, one of the classic virtues of using a word processor or the tradtional mechanical typewriter, is how easy it is to correct mistakes. Holy shit, kid... Exactly how fucking stupid are you, really? Try to understand the concept of "humour" before the next time you reply to an example of it. Sheesh... [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link\|http://z.iwethey.org/forums/render/content/show?contentid=71575\|Ashton Brown]
Post #201,679 by systems 4/2/05 5:56:19 PM Reply	Re: Holy... In the agile modeling literature, some have recommended using a digital camera to take photos of diagrams drawn on white boards, they also speak about throw away models So, it didnt have to be a joke, anyway In reply to the XML comments, you can draw a UML diagram, and save it in an XMI Xml file, I am saying, I would love to write an XMI file in Emacs, and transform it to a jpg or whatever, or view it in a graphical diagram editor. It's a lot more practical to write XML docs, than to draw a diagram graphically in a graphical diagram editor. Plus, if all your docs, are writen in XML (see XML publishing), you diagrams can be integrated in the rest of your docs, instead of being linked as a jpg.
Post #201,683 by broomberg 4/2/05 6:42:51 PM Reply	I don't KNOW it was humor We take pictures of whiteboards all the time at part of our design process. On the other hand, "systems" is obviously an academic/student with no real world experience. Seems like he's the snobbish student in Good Will Hunting who pontificates what he just learned about in class, only to be crushed a few minutes later by someone who has read a lot more than him. [link\|http://www.un-official.com/GWH/GoodWillS.html\|http://www.un-offici...WH/GoodWillS.html] Search for "Of course that's your contention" After all, this is the guy who feels which computer language you code in should have nop bearing in your design. What an idiot.

Welcome to IWETHEY!