Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Graphics Programming Software IT Technology

How Do OOP Programmers Flowchart? 134

Posted by Cliff from the taking-an-overall-view dept.
Lew Pitcher queries: "I recently attended a presentation of a code documentation tool that, among other things, produced a flowchart of the analyzed code. The vendor sells this one product for analyzing both mainframe code (COBOL, 390 Assembler, PL1, etc.) and 'distributed' code (C#, Java, C++, Smalltalk, etc). I haven't kept up with the 'modern' techniques (I prefer Nassi-Shneiderman charts, but I still have my flowcharting template), and wondered if modern 'OOP' programmers use flowcharts. If they don't, what is the preferred technique for diagramming an OOP program?"
This discussion has been archived. No new comments can be posted.

How Do OOP Programmers Flowchart? More

How Do OOP Programmers Flowchart?

Comments Filter:

  • Legos (Score:5, Funny)

    by Anonymous Coward on Tuesday March 30, 2004 @09:43AM (#8713624)
    I build my objects out of legos.

  • In uml (Score:5, Informative)

    by sporty ( 27564 ) on Tuesday March 30, 2004 @09:46AM (#8713650) Homepage
    In uml, with activity diagrams, and class diagrams.

    • On the mac... (Score:1, Informative)

      by ABaumann ( 748617 )
      this is really easy to do with Omni Graffle. It's a sweet program for UML design, and it comes with OS X

      • Re:On the mac... (Score:3, Informative)

        by Joe Tennies ( 564856 )
        OmniGraffle doesn't come w/ OSX. It's either $70 or $120 (standard or professional).
        • It does, or at least it did with my Jag. Not the Pro, but still is a great product.

        • OmniGraffle doesn't come w/ OSX. It's either $70 or $120 (standard or professional).
          It does.
          My Mac had it preinstalled. And my OS X 10.3 Upgrade CD containes it as well. Furthermore the upgrade from the Web Site is free also.
          angel'o'sphere
          • "My Mac had it preinstalled" != "It comes with Mac OS X"

            When you buy the hardware, you not only get a free copy of Mac OS X but you also get free copies of whatever software Apple happens to be bundling with that particular model this week. (or rather, whenever yours happened to be manufactured.)

            They typically bundle things like AppleWorks or games like Otto Matic or Bugdom with consumer machines (iMac, eMac, iBook) and things like Graphic Converter or OmniGraffle with professional machines (PowerMac, P
    • What softwear, preferably Free/Open, would you recommend for this?
      • http://gentleware.com/ has a software called poseidon.

        It's a good tool, not suber uper, the best, but it's pretty neat.

        -s

      • You can use dia [lysator.liu.se] for all kinds of things.

      • I downloaded the month-long free trial version of Pacestar UML Diagrammer [pacestar.com] at work recently. I only used it for class diagrams, although it obviously does many other types as well, but it produced nice output and was very ease to use. I'd certainly recommend giving it a try.

      • There are two kinds of tools. One is a drawing tool. Great for diagrams you have to drop into documentation. dia is a great example of this. The other kind generates the code for you, but the diagramming is more primitive. Umbrello and Argo are examples of this.

        I personally hate things that try to generate code for me, so I prefer the former style of tool.

  • If you've got any sense you don't use flowcharts (Score:5, Informative)

    by WolfWithoutAClause ( 162946 ) on Tuesday March 30, 2004 @09:50AM (#8713694) Homepage
    The nearest thing to flowcharts that are used in OO are:
    • state diagrams
    • message sequence charts
    Neither are flowcharts, and if you try to use them as flowcharts (which I have seen done :-( ), bad things (tm) happen to your design. (States on state diagrams are states that parts of the system are supposed to be in for extended periods- message sequence charts are different because the flow is usually multitasking/parallel processing).

    Personally, if I see somebody drawing a flowchart, I know they aren't currently up to scratch (which doesn't mean that they can't get better).

    Actually, flowcharts are good for telling users what to do, and for similar reasons, might be appropriate for designing test scripts. But for the system- nope.

    • Re:If you've got any sense you don't use flowchart (Score:4, Interesting)

      by laughing_badger ( 628416 ) on Tuesday March 30, 2004 @10:33AM (#8714188) Homepage
      Personally, if I see somebody drawing a flowchart, I know they aren't currently up to scratch (which doesn't mean that they can't get better).

      [Looks up from flowchart] None taken...


      Actually, flowcharts are good for telling users what to do, and for similar reasons, might be appropriate for designing test scripts. But for the system- nope.


      This depends strongly on the system.

      For a system that takes in data, performs computations, and spits out answers, a structured design using flowcharts is often appropriate.

      That said, implementing part of that design using OO code can be useful. For example, using C++ with a matrix class to do geometry based processing. The actual process may best be described as a flowchart though.

      OOA/OOD/OOP are not the silver bullets. I've seen a major revision of a large commercial computational program wither on the vine due to misunderstanding how to best apply object based thinking. 'Everywhere' is not the right answer.

      • Comment removed (Score:5, Informative)

        by account_deleted ( 4530225 ) on Tuesday March 30, 2004 @11:04AM (#8714572)
        Comment removed based on user account deletion
        • This goal is often achieved with a Data Flow Diagram ...[snip]... Eventually, we got to UML from there after 10-15 years of haggling and stumbling; some argue that it still isn't working out so well.

          Yeah, well. Some of us are complaining about the lack of dataflow diagrams in UML ;-) If it doesn't even support that, what do we need a standardized notation for? Drawing stick-figure men?

          • DFDs can eb doen with Activity Diagrams.
            If you use stereotypes and load appropriated pictures into your CASE system, they even look like DFDs.

            UML stands for Unified Modelling Language. My I emphasize: Language.

            Its a language like C++ and Java and Ada or what ever your personal prefered language is. You can do everythign with it as long as yoour CASE system is at least a little bit up to date.

            That means you can define your own meaning for structures, and you can defeine your own graphics for stuff you mis
            • Interesting. Last time I heard, on some UML course I was forced to participate in, at my last job, the hired expert said that the UML gang didn't like dataflow diagrams, because of some ideas they had about use of model checking (use of formal methods) in the case tool, or something like that, which basically meant that DFD would break UML somewhat. Not that I've really investigated this issue myself, as I'm happy to draw DFD's on napkins anyway, and never really saw the point of having one unified notation
              • Then I woul dsugest to google for magicdraw (I think nomagic.com).

                Its a Java based case tool, also with XMI export.

                To transform an activity diagram into a Flow Charting tool or a Data Flow Diagramming tool you only need to look at the configuration options.

                Define an stereotype for an activity and a stereotype for a flow, load the appropriated graphics into the tool for the stereotypes you defined. A lot of CASE tools support that.

                Yeah, you are right, its a pitty that EA is for windows only. That tool is
                • I have no trouble accepting that you can coax your CASE tool into drawing something that looks like a DFD, I can't see how you can preserve it's semantics in UML. I can probably coax my CASE tool to write modernist art too, but it has absolutely no meaning in UML (not that modernist art is particulary meaningful for anyone, but that's besides the point).

                  Since activity diagrams are basically flowcharts, and flowcharts and DFD's are totally different things, I can't see how activity diagrams can be DFDs too

                  • Ah, ok.

                    Understood :-), I think at least.

                    The elements on UML diagrams are just the building blocks of the graphical language. Just like "int", "if" and "class" are the building blocks of your programming language.

                    As you can use an int to code a date, or an age or a length in millimeters you can use an activity from an activity diagram to express everything e.g. a process in a DFD.

                    The CASE system does not interpret your usage. The reader of your diagram does. Just as the compiler in a programming language
        • Data Flow Diagrams are a great tool for mediating between your customers and your programmers. The customer sees his business processes laid out in a format they can understand while the programmer sees those processes laid out in a way that clearly describes the requirements and boundries of the problem. I typically use UML class diagrams and sequence diagrams for design work once I have done a DFD for the customer. There may well be UML diagrams that can allow the customer and programmer to communicate
      • Well, I kind of think of it as a 'goto considered harmful' sort of deal. There's probably situations where a flowchart is exactly the right diagrammatic tool to use for the task in hand; in which case you still shouldn't use it because everyone will laugh at you :-)

        Actually, in situations like you are describing pseudocode is good.

        I've seen a major revision of a large commercial computational program wither on the vine due to misunderstanding how to best apply object based thinking.

        Lots of people don'

    • This is not entirely correct - there ARE, in fact, flowcharts in OOP. Besides the Rational model IS extensible so you can create your own diagram types. It depends on the vendor that supplied your modeling tool - some vendors don't offer the flowcharting diagrams. I am not saying that flowcharts should be used for modeling designs. But they are very useful when you are doing presentations in front of customers.
    • I prefer a less formal design approach best exemplified by this guiding principle:

      A design should be written on the smallest napkin possible, but not smaller.

      Anything more than that is gravy. ;)

      • A design should be written on the smallest napkin possible, but not smaller.

        That's as insightful as it is funny.

        Programmers should resist the urge to pull out a computerized tool when modeling. If it doesn't fit on a napkin, it's probably not abstracted enough to be useful to those who need it. If you need to "zoom in" on one of the boxes on the napkin, pull out another napkin.

        Do you need to archive it on a computer, perhaps on an internal Wiki? Scan it. Does it need to be prettier than a scan

        • For those who find napkins hard to draw on, use small sheets of paper instead. Just don't reach for that drawing tool! You'll end up spending all of your time figuring out how to make that font bigger and how to keep the lines from crossing inappropriately rather than just getting on with it and drawing the model.

          While I have a lot of sympathy for the view that pencil and paper are an under-rated combination these days, I think that's going a bit far.

          I've recently spent a fair amount of time drawing r


    • The nearest thing to flowcharts that are used in OO are:
      * state diagrams
      * message sequence charts

      Not quite right. The nearest thing are activity diagramms. Basicly they *are* flow charts.
      Activity Diagrams support more even, they can be mixed with states and have event sources and sinks and can show object flow (work flow).

      Personally, if I see somebody drawing a flowchart .... Actually, flowcharts are good for telling users what to do, and for similar reasons, might be appropriate for designing test
      • If you have a large system or a complicated system, the high level design should be done with flowcharts/activity diagrams.

        In my experience they are rarely useful. They manage to fall in the no mans land between accuracy and useful approximation; getting the worst of all worlds. Pseudocode is generally better.

        How do you do that if you don't have every line of code in your mind?

        Simple. I don't work on subsystems with more than 200,000 lines of code.


        • Simple. I don't work on subsystems with more than 200,000 lines of code.
          Fine. And I would asume a system composed of lets say 25 such subsystems might be a perfect case for using high level activity diagrams as documentation or as start of planning(before coding).
          You still owe me the answer how you like to shift over such a subsystem to a new worker taking over your position when you move on to the next challange ... he only has code and pseudo code.

          How far away from true code is that pseudo code, anywa
          • You still owe me the answer how you like to shift over such a subsystem to a new worker taking over your position when you move on to the next challange ... he only has code and pseudo code.

            I wouldn't know, I've never been in that position; I usually hand them an inch thick document as well as the code. It just doesn't contain any significant flow charts because they suck.

            From what I can tell, the systems you work on are so heavily constrained that a flowchart actually makes sense.

            The systems I have wor

            • Sounds like a challange.
              So how do you transfer knowledge then? I completely agree that a one inch document is invalid before one is able to read and understand it.
              If your prblem domain is that complex I would asume you use message charts or sequence charts (instead of activity diagrams/flow charts), but using no graphics at all seems strage to me. So, do you use them? Or what do you use else? How often do requirements change, or new features come up?

              angel'o'sphere
              • In a real sense; the documentation is just introductory and/or a summary of the system from a few different angles.

                Ultimately, it's just a map, and the map is not the territory.

                I've written the documents, I've done week long teaching on the system; I've given a sort of apprenticeship to students (generally given them bugs to fix helps quite a lot.)

                They all work to a degree.

                Ultimately though; the code is the real deal; people just have to learn it; it takes months/years.

  • UML Sequence diagrams (Score:4, Informative)

    by cogpp ( 195632 ) on Tuesday March 30, 2004 @09:51AM (#8713710)
    UML sequnce diagrams can be pretty useful to show these things. Especialy if you have asyncronus events, or multiple threads or processes, which ordinary flow charts dont model very well. PDF on sequnce diagrams [objectmentor.com].

  • UML State (or Activity) Diagrams (Score:3, Informative)

    by sl956 ( 200477 ) * on Tuesday March 30, 2004 @09:56AM (#8713761)
    If they don't, what is the preferred technique for diagramming an OOP program?
    Most of us probably use UML State (or Activity) Diagrams.

    UML State Diagrams come from David Harel's work on Statecharts. Statecharts constitute a broad and popular extension of finite state diagrams
    While there are some differences between original statecharts and UML state diagram, the best introduction remains imho David Harel's paper : Statecharts: A Visual Formalism for Complex Systems (Science of Computer Programming 8-3, 1987). It is available onlline here on David's home page [weizmann.ac.il].
    You can also rely on any good book about the UML (i recommend Addison-Wesley Object Technology Series).
    • You can also rely on any good book about the UML (i recommend Addison-Wesley Object Technology Series).

      My favorite is UML Distilled [amazon.com] by Martin Fowler. It tells you what all the symbols and diagrams mean, without getting bogged down in lots of methodology that most people don't care about. If you're just going to use UML as a standard way of drawing design diagrams, you don't really need a 2" thick book on it.

  • Never used them (Score:5, Insightful)

    by Scarblac ( 122480 ) <slashdot@gerlich.nl> on Tuesday March 30, 2004 @09:56AM (#8713764) Homepage

    I've been programming for 19 years now; started my CS study 12 years ago; programming professionally for a few years. I used Java, and fast development languages like Python. I've never seen a flow chart in practice, let alone used one. So it's a bit hard to say.

    Somehow flow charts seem fit only for relatively short programs, that have a clear flow from A to B. My programs are web apps that constantly react to requests from web forms that are sent in, supported by a bunch of scripts running from cron to periodically update database stuff. Program-wide, there is no single flow.

    On the method-level (or the Action level, I build a large J2EE app with Struts), we could use flow charts I suppose. But they look pretty cumbersome; mostly I just write out what the method is going to do in a comment in English and/or pseudocode, and from that I write down the code.

    What each action is supposed to do, and what each method of an object is supposed to do, that is (should be) designed beforehand. There you get tools like UML, if you want to use something like that. What we design is the data objects, and the interface they should expose, and so on.

    How those methods do their work is decided at coding time, and is the only place where traditional flow charts seem applicable.

    Just some thoughts, I don't know if I'm making sense, since mostly I get very little time for any design at all, in reality...

    • At first I was surprised that with 19 years of experience you had never seen a flowchart in practice, then I read your post again and saw "programming professionally for a few years" . That explains it.

      10 or 20 years from now programmers may be saying "UML, nobody but old farts use that anymore". And so it goes.
    • I've seen a tool that produces flowcharts from individual functions in a variety of languages. Now, as a modelling tool it's pretty useless, but as an aid to documentation and as a debugging tool it was great. Note that it doesn't REPLACE english language docs, but a quick graphical overview of a complicated function made it alot easier to get up to speed on someone elses code.

  • It's pretty straightforward... (Score:3, Interesting)

    by stienman ( 51024 ) <.adavis. .at. .ubasics.com.> on Tuesday March 30, 2004 @10:01AM (#8713817) Homepage Journal
    OO programming can be procedural, and follow a normal flow chart. All OO does is make it easy to create data structures with built in rules/procedures on how to perform various operations on them (such as addition on strings). It's just as simple flowcharting an OO program as any other procedural language.

    Event triggered programs can be a little different, but each event is simply a string of operations - a procedure which is easy to flow chart. You simply have lots of little flowcharts instead of one large one.

    OO does have data structures which are handy to document in a visual way. These would not be flowcharts, but they may include flowcharts to properly document the methods/functions/operations effective on the data. The documentation of the data itself would not be flow chartable - this is where UML is handy.

    Since a program is a sequence of instructions with loops and conditional operators, whether it's procedural or event triggerred, it's fairly strightforward to flow chart it. The mere definition of a program also defines a flow chart. It's going to be awhile before we get reasonable processors which perform work without following a logical sequence of steps - mainly because it's hard for us humans to understand how something can be done in a way that we can't easily visualize or do ourselves. The real machine intelligence won't happen because machines will be smarter at doing the things we do, it's because they will do things we can't do.

    -Adam
  • Here's the new "modern technique"... pay attention, it gets complicated!
    .______________.
    | o o o o o o o|
    | Outsource to |
    | o .India. o o|
    |______________|
    o o o o|o o o o
    o o o .V. o o o
    o o o END o o o

    --Stephen

    • Twisted technique... (Score:4, Funny)

      by JediTrainer ( 314273 ) on Tuesday March 30, 2004 @11:50AM (#8715153)
      What if I outsourced my *own* job to India? Pay some guy $100 per month to do my job, so I can sit on my ass all day and play games? Heck - get two guys - it's time for a raise!

      Anybody try it? Can it be done?
      • Do you realize that you are a genious?

        This is why outsourcing is good for the economy. If we all did it, we would all be rich.

        American companies are more productive if jobs can be more cheaply done overseas. Americans that work for American companies can make more money if American companies are more productive. You just have to do something that you can do better than 5 guys in India.

        If you can't find something that you can do better than someone else who will do it cheaper - then who owes you anything?
      • Sure, it can be done. What you're describing is setting up your own consulting firm and outsourcing the technical work to India. So you're traiding your technical job for one in Sales and Marketing, something that can't be easily outsourced. But if you think you'll "sit on my ass all day and play games" you're sadly mistaken.

  • as already mentioned by others (Score:4, Informative)

    by jeffy124 ( 453342 ) on Tuesday March 30, 2004 @10:08AM (#8713903) Homepage Journal
    The Unified Modeling Language.

    Start Here [omg.org], then try google for more introductory articles that are out there.

    If you want books on the topic, I recommend UML Distilled by Martin Fowler for a quick intro, then branch out from there. (There's hte Object Technology [awprofessional.com] series from Addison-Wesley, which are usually very good, but they're not the only UML books out there) I also recommend you download a UML tool (there are a bunch out there - free as in beer, Open Source, or try a commercial trial version)

    As for flowcharting, there are several model types in UML to handle it. Activity diagrams come immediately to mind (these are very close to the classic flowcharting techniques), but state charts and sequence diagrams are useful also to supplement an activity chart. Also look into the structural models - class diagrams, deployment charts, etc. when assembling/designing your program.

    UML is language independent - meaning it's not explicitly tied down to one specific language. Although, it is useful to keep in mind what language you plan on using when authoring in UML.
  • because OOPrograms don't have flow control.
    The flow just sort of hops around with no
    real relationship between what is written in
    the code and the flow of control. You see
    one of the great advantages of OO'ation is
    that code no longer corresponds to flow of
    control. This is usually called dynamism
    or genericity, but you may also know it as
    job security.

  • KISS (Score:3, Interesting)

    by Salamander ( 33735 ) <jeff.pl@atyp@us> on Tuesday March 30, 2004 @10:19AM (#8714018) Homepage Journal

    I've tried a lot of the fancy UML tools, but they're really not any better than a very simple drawing program. The purpose of a diagram is to convey information. For that purpose simpler is usually better, and a diagram that uses too many specialized symbols to denote subtle nuances is not simple; that stuff should be described in the text. Maybe a case can be made for the extra symbology in a class diagram, but not in a flowchart or timeline. If your flowchart has more than about twenty items, or more than four types of items, or can't be drawn without crossing lines, it needs to be broken apart into a top-level flow and separate diagrams for secondary flows. Any simple box-and-line drawing program should be able to handle that, though a little bit of intelligence in routing lines doesn't hurt. Focus on the information, not the tools.

    • Re:KISS (Score:3, Interesting)

      by angel'o'sphere ( 80593 )
      Hm,

      A UML tool can do two things a simple diagramming tool can't:
      * generate source code
      * reverse engineer source code

      As a standard compliant CASE system usually supports XMI export (a defined XML standard) you are free to transform the XMI with XSLT into any form of code.

      Furthermore: how much time do you spend analizing? How much time designing? How much time coding?

      You sound as if you would analyze/design one week and code after that 6 weeks. So you spend in total 7 weeks.

      I prefer to analyze one week

      • Re:KISS (Score:3, Insightful)

        by Salamander ( 33735 )

        A UML tool can do two things a simple diagramming tool can't: * generate source code * reverse engineer source code

        The poster wasn't asking about source-code generators. He was asking about diagrams. In terms of diagrams the UML-oriented tools are no better than simple alternatives, even if they offer other features as well. Is a text editor no good just because it's not a full-blown IDE? Not if you just want to edit text.

        Furthermore: how much time do you spend analizing? How much time designing? H


        • Of course you push UML tools because you have a business interest in doing so; maybe you should have skipped that dozenth UML class and taken an ethics class instead.
          Probably you should have taken an ethics class?
          I have no interest in pushing UML tools, I'm not in an UML tool company. I'm an OO consultant, focusing on software processes, teaching to use the right tool for the job. If you process level is so "low" that UML -- not even talking about an UML tool -- is out of scope for you ... then we simp

          • I have no interest in pushing UML tools...I'm an OO consultant

            Those two statements are inconsistent.

            teaching to use the right tool for the job.

            Obviously not.

            If you process level is so "low" that UML -- not even talking about an UML tool -- is out of scope for you ... then we simply speak different languages here.

            Ahhh, another gratuitous insult. You're the one who started with the condescending attitude, buddy. Don't whine when it rebounds on you. Our process level is doing just fine, and you h

            • Well, you started to take my post out of context.
              You said diagrams are enough ... UML tools are not needed. I said UML tools give you more than just diagrams ... you continued claiming that I need to say that out of business inerests :D .... I could continue, but the posts are easy to follow for everyone.

              Sorry that I'm arrogant. I know that. And I don't need a job ... my customers stand at my door and want me :D

              Why, you ask? Because I gave all my customers an independent objective councel. I refuse at lea
  • For me at least the code is so much more abstract and readable then it used to be in the old days, that it doesnt really need information outside of the code to understand its functioning, it still needs documentating ofcourse :) Designing is another story, but a would never use a flowchart for that because it would never fit in one.

  • Re: How Do OOP Programmers Flowchart? (Score:3, Informative)

    by manavendra ( 688020 ) on Tuesday March 30, 2004 @10:38AM (#8714249) Homepage Journal
    OO programming defines and to some extent mandates more concrete and phased flow-control diagrams than a regular flowchart.

    In typical structured programming, there is more emphasis on control flow. Furthermore, for any modestly sized software, you will need flowcharts withy varying detail - those depicting the overall flow, flow for a particular user, flow within a particular module, and so on. This essentially leaves the decision of detail to each organization and/or author, and we can thus argue this approach introduces a certain vague-ness.

    OOP, on the other hand, provides more detailed and clearer demarcation for each of these entities.

    • Use Cases - model the functionality of system and the path of interaction of different users with it.
    • Activity Diagrams - depict the dynamism of the system and model the control flow from activity to activity. You can use these to model workflow and business processes.
    • Statechart Diagrams - depicts the dynamic response of the system in response to external stimuli.
    • Sequence Diagram - describes the interactions between different components (classes) in terms of message/data exchange over time.
    • Class Diagram - some call it the backbone of OOP. These diagram depict the various entities in your system and the relationships/associations among them.
    • Object Diagram - describe the snapshot of entities in the system at a given time. You can use these to examine the overall system state at any time, and verify your class diagram
    • Package Diagram - More useful for teams/people responsible for managing deployment and building the system, package diagrams describe the grouping and packaging of your classes.
    • Deployment Diagram - depicts the physical resources in the system and how they are deployed (locally, remotely, whether as nodes, connections, etc.)
  • Judging by what I see in the code at my work place, flowcharts are in the same realm as internal documentation. In other words, not used at all. To code in the modern environment, you just write obtuse poorly designed code and rely on the statement "code should be self documenting". This doesn't mean your code actually has to be self documenting. You just give that excuse whever anyone mentions actually expending effort to produce inline documentation. I suppose the parallel statement for you would be "code
  • There is a U.S. "ANSI" (now "NCITS", I think) official standard for defining flowchart formats. ANSI standards come up for review and revision, or retirement. every five years.

    Each time the flowcharting standard comes up, there is some discussion about whether to retire it. They always decide not to, because there are many contracts that specify a flowchart, and would have to be renegotiated if there were no such standard. The most reasonable change, were it to be changed, would be to allow a single bla

  • At my school [msoe.edu], they teach the students to use UML [omg.org].
  • Not the source code. In today's business environment most of the development we do involves databases and complex relationships. Use a flowchart to analyze where the data starts, what needs to happen to it and where it needs to wind up. The UI and the code will take care if it's self.
    • Whereas the diagrams that show relationships between fields, sorry, "columns" in RDBMs look so much like ants that had been chased through spilled ink that *no* *one* can make head or tail of 'em.

      This younger gen'ration just don't understand multi=level flow charts.

      Aside: Do meddle in the affaird...? Y'know, if they're crunchier, some like to roll 'em in powdered sugar, which is bad for their fangs.

      y Ddraig Goch, eh? Cymry?

      mark, y Ariandrake, cymrophile

    • In today's business environment most of the development we do involves databases and complex relationships.

      In your business environment, and many others, no doubt that is true. However, "enterprise applications" (or databases, as we used to call them) represent only a significant fraction of development work, not by any means all of it. A lot of real programs still use real algorithms that do more than construct a SQL query and whizz it off to some server via the latest and greatest RPC trick, y'know. :

  • Whiteboard... (Score:5, Insightful)

    by SuperChuck69 ( 702300 ) on Tuesday March 30, 2004 @12:18PM (#8715563)
    When I have a complicated problem that requires some design (which is, unfortunately, not very often), I use a very complex system which involves sketching some boxes on a whiteboard, often connecting them with vague lines. I occasionally jot some method names down next to or inside the boxes

    Personally, I'm wary of any formalized system of object design (UML being the prevailing method at the moment). UML is a beast designed to design the hell out of anything that got in its path. Learning UML is roughly as complicated as learning Hebrew, with the drawback that more people actually understand Hebrew.

    Most of my experience with UML and other formal object languages involve one individual scrawling archaic symbols (which may well be astrology charts) on a whiteboard whilst everyone else in the room constantly ask "what does that symbol mean?" The designer invariably explains the symbol, in as condescending a tone as possible.

    I don't believe I've actually met anyone who uses formal modelling languages because it makes design easier; most seem to learn them solely for demeaning those who don't know them.

    Given that the goal of these languages is to communicate design, they must be failures. Rather than simplify the communication of a design, they complicate it. Really, it makes no more sense than me using Latin for all my design notes, just to insult my barbarus coworkers. Well, that does no good.

    I've found that using simple symbols such as "abstract" to denote an abstract class works just fine. Works fine for me, saves explaining what a lambda symbol means, and clearly explains its intent as an abstract class...

    • Well, guys like the three Amigos have to make a living. If they just said "draw a few simple diagrams and describe in text how the system is designed" how can they make money?

      The fact is that the (human) language a software team speaks is the most powerful and effective way to communicate overall. Diagrams can be helpful, but they'll always be a supplement.

  • Why do you need a graphical representation? (Score:5, Interesting)

    by CatGrep ( 707480 ) on Tuesday March 30, 2004 @12:18PM (#8715572)
    A lot of folks will tell you that they use UML in place of flowcharts for OO design. I say that the UML emperor is naked.

    Chip designers (I used to be one) in the old days (before about '92) used to use schematics which are pictorial representations of their designs. But in the early 90's HDLs (hardware description languages) bagan to creep in. Now you rarely find schematics used for digital design. It's all done in HDLs. Why did this happen? Mainly because it's a whole lot easier and more powerful to describe a circuit with an HDL. You don't have to draw all those wires to connect everything. You can describe things at a very high level, such as an adder to add two 32bit values: A + B (where A and B are 32 bit vectors). What could be simpler.

    Another reason that schematics were abondoned is that it's a lot easier to parse text than graphics. The UML promoters should take note.

    Now the UML folks are essentially trying to take software design back to the schematic age. The hardware people learned that schematics are not the best representation.

    The answer is to program at a higher level of abstraction. This might mean chosing a higher-level language to prototype in (I like prototyping in Ruby) or it might mean using techniques like state machines, for example.
    • Mainly because it's a whole lot easier and more powerful to describe a circuit with an HDL. You don't have to draw all those wires to connect everything.

      While that may be so, for software design of any significance, you're going to need to express relationships that will be difficult to predict a priori. Using a design language might be easier to produce, but it's certainly no more expressive of the overall design than a diagram.

      Another reason that schematics were abondoned is that it's a lot easier to p

      • I'd wondered why there was this whole XMI thing that was running around the UML editor industry

        OK, so UML editors are now able to spit out XML. That makes the concept a bit more usable. Now we have something to grep.

        A prototype and a spec are two completely different things. They each have their place, and they aren't wisely exchanged.

        Perhaps, but add 'test-first' development with unit tests to the mix and you've got an executable spec. If I can use the same set of unit tests for both my prototype
    • We're talking software here, not hardware. If you have some objections to UML, please state them in software terms.

      p.s. There are valid objections to UML, it's just that your analogy isn't one of them.

      p.p.s. And no matter how many valid objections you come up with, management likes to see UML, so it's all pointless.
      • We're talking software here, not hardware. If you have some objections to UML, please state them in software terms.

        I'm just relating what I saw happen in another design community. Creating hardware these days, btw, is very much like creating software. Design languages, compilers, etc. I do software for hardware design automation.

        p.s. There are valid objections to UML, it's just that your analogy isn't one of them.

        Why not? as someone who has been on the other side of the wall, I'm telling you about
  • One of the instructors at my University is getting us to use "Collaboration Graph Notation". (Note that this appears to be different from UML Collaboration Diagrams). I'm just wondering if anyone ever uses these in practice because they, and the book [usecasemaps.org] that introduces them seem like the biggest bunch of BS ever. The book reads more like something written b y a philosopher rather than a software developer.

    So does anyone actually use this? What's the advantage over UML?

  • There is no straight analogy in OO for a flow chart or DFD. But activity diagrams ( here [kennesaw.edu], here [dotnetcoders.com], and here [agilemodeling.com]) serve a similar function. They provide a high level of abstraction that can be done with a picture.

    One poster said to use a "high level language". I agree, at least with the first two words. I mildly disagree at the word "language". Some people think better in words, others think better in pictures.

    What's important is that you don't try write your detailed code using pictures. People who map on

  • When whiteboarding, we sometimes flowchart -- usually just the simple (and thus VERY QUICK to draw) boxes and arrows. Rarely have we used other types, as they take more time.

    However, without the whiteboard, I would have to say that I rarely do so.
  • You are probably being serious. Oh, well...

  • What design? (Score:3, Insightful)

    by Anonymous Coward on Tuesday March 30, 2004 @03:52PM (#8718418)
    I haven't worked with an OOP programmer yet who has used flowcharts, let alone a design beforehand. Heck, I haven't interviewed with a company yet that used designs to model a program. These days, it's all seat-of-the-pants.

    That's not to say that there aren't real engineers out there, or that designs are a bad thing. Just that whenever I talk of actually designing a product/project to nail it down, people look at me like I'm crazy. Who would have thought that wanting a specific goal to shoot for was so foreign a concept.

    Nobody wants to do research. Employers change feature lists with the whim of the customer du jour on the phone. Programmers waste time by throwing useless gadgets and doo-dads into software that never works properly, and would never have gotten past the design stage.

    In these insane times, you get your head handed to you if you demand designs, documentation, and working code. Fix or make reliable software and you're out of a job.

    • Re:What design? (Score:2, Insightful)

      by hInstance ( 709126 )
      My experiences have been very similar. As a rule my employer (now ex-employer, because as you suggest, I'm out of a job) would always prefer/reward programmers who produced shoddy work quickly (with some unspecified amount of QA time needed afterward) over programmers who spent more time planning up front (with very few bugs in the implementation).

      Hidden costs are a bitch. (Or as Robert Glass puts it more eloquently in Facts and Fallacies of Software Engineering, "the hard drives out the soft").
  • About a decade ago, I believe in Gerald M. Weinberg's The Psychology of Computer Programming, I read about a research study that tested the hypothesis that flowcharting is beneficial. They found that it was of no benefit at all. (If I recall correctly, what they found was beneficial was delineating chunks of code by separating them from each other with blank lines).

    If traditional flowcharting isn't beneficial for traditional programming, why would O-O flowcharting be beneficial for O-O programming?

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close