Slashdot Mirror
How Do OOP Programmers Flowchart?
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?"
I build my objects out of legos.
In uml, with activity diagrams, and class diagrams.
-
ping -f 255.255.255.255 # if only
- state diagrams
- message sequence charts
Neither are flowcharts, and if you try to use them as flowcharts (which I have seen donePersonally, 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.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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.
Flowcharts are a throwback to when computer programming was considered the same as other disciplines like mathematics or engineering.
As we know now, computer programming is something else. It's a combination of stuff and software is almost a living entity that is always changing.
The only people I see using flowcharts are engineers that think they can program or old farts who refuse to accept new ideas.
The ratio of people to cake is too big
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.
You can also rely on any good book about the UML (i recommend Addison-Wesley Object Technology Series).
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...
I believe posters are recognized by their sig. So I made one.
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
--Stephen
Did you ever notice that *nix doesn't even cover Linux?
The Unified Modeling Language.
Start Here, 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 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.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
the flowchart lie
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.
-I like my women like I like my tea: green-
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.
Slashdot - News for Herds. Stuff that Splatters.
Legos?!?
HAH!
Your Legos are FAR inferior to my Duplos! *cough*ASP.NET*cough*
In Soviet Redmond, software programs you!
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.
[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.
Help children born unable to swallow - www.tofs.org.uk
The UML (unified modelling language) is the general diagramming technique for OO developers. It has no construct explicitly intended to model the code inside a programm, although you could (ab)use activity diagrams and/or state diagrams for this, which was mentioned already.
It is expected (although not always followed) that OO programs are segmented into much smaller pieces than classic COBOL monoliths, so the need for a flow chart kind of diagram is less obvious.
A sequence diagram (also mentioned in earlier posts) is not suitable as a flow chart replacement, because it is (by definition) sequential, depicts just one scenario and does not support branches and loops very well (except through non-standard annotations). It can be used to model a scenario for the interaction between pieces of the program however. The same applies to the UML collaboration diagram.
A state diagram might be used to model the possible states of an object (or an interface) and the possible transitions between them. This is not an "inside view" of the code, however, but rather a model of an object's or an interface's behaviour from the outside perspective.
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.
http://efil.blogspot.com/
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 describes its own flow" instead of actually putting down an analysis of what leads to what. In emergencies you can always provide the equivalent of the occasional comment for one hundered lines of code: Start->GetData->ProduceData->End.
Welcome to modern programming. Good luck.
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 blank sheet to qualify as describing any program.
Most contractors nowadays run a program over the completed source code, and produce a several-inch-thick line-printer listing. It gets stuck in a warehouse with all the other ones, stored for N decades, and then shredded on schedule, all at government expense.
This goal is often achieved with a Data Flow Diagram which many people mistake for a flow chart. Structured analysis/design techniques from the 1970s and 1980s developed the DFD concept as part of the problem analysis phase. Search for the likes of Coad, Yourdon, DeMarco, Gane and Sarson. Some of these names are still familiar in the OO design world. The key differences between a DFD and a flow chart are:
In the 1980s, lots of people tried to slap object-oriented deisgn onto structured analysis using various techniques (like making the processes or data stores the objects). It didn't work out so well. 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.
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't seem to be able to hack it for some reason- with OO systems (and non OO too), knowing what makes a good object/structure is an art.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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.
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).
Other OO proponents will describe OO differently. The biggest problem with OO, and this leaks into UML also, is that there is generally very little consistency from one practitioner to another. OO is just plain wishy-washy. I find procedural and RDBMS more consistent overall. Even bad procedural tends to fit certain patterns. However, bad OO can look very different between the various culprits.
OO "patterns" are supposed to fix this, but they don't, partly because they do things in code that are best left to the database in my opinion, and because one has to mix patterns in practice, making it hard to know where one ends and the other starts. The end result is a big tangled web of classes and objects with no underlying theory or forest-level pattern between different practicioners. At least one generally knows that procedural code is divided up by tasks and events, and the noun model is mostly in the database, not in the code. It is a fairly predictable division of labor between nouns and verbs. (Whether this is good or not is perhaps another discussion, but *at least* it offers consistency.)
I am posting this anonymously because pro-OO people don't like to hear this, and mod me down. Truth hurts.
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.
Hmm... let's check out developers.slashdot.org to see what the latest developer news is. Hmm... COBOL... COBOL again, I really should check out this COBOL language. Maybe my FORTRAN just isn't cutting it anymore.
Idol Star Astronomer
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?
You can accomplish anything you set your mind to. The impossible just takes a little longer.
NOT
At my school, they teach the students to use UML.
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.
Meddle thou not in the affairs of Dragons, for thou art crunchy and with most anything.
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...
:wq
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.
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 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?
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 parse text than graphics. The UML promoters should take note.
Gee, I'd wondered why there was this whole XMI thing that was running around the UML editor industry. Seems like it's not just text but XML, so there's not even the trouble of writing their own parsers. How novel! For humans, on the other hand, it's much easier to parse the graphical representations of UML, from the rough conceptual level of "so how does this work" all the way down to the specification level, thanks to the rigidity of UMLs definitions. (Granted, yes, a set of UML diagrams does not a spec make, but you need very little in the way of supporting documents to round out a very usable spec.)
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.
If that's your answer, I'm not entirely sure you caught the question. While yes, I completely agree that a Ruby prototype is an enjoyable and useful execisize, and that your programs might even be completely literate in Ruby, they aren't a substitute for diagramming (or spec) of some kind.
A prototype and a spec are two completely different things. They each have their place, and they aren't wisely exchanged.
IP is just rude.
Is there any torture so subl
this is really easy to do with Omni Graffle. It's a sweet program for UML design, and it comes with OS X
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 and my final code (which I can) then I know that my final code behaves exactly as it should according to the executable spec.
What good does the graphical representation do me, I've got to keep my graphical representation in sync with my actual code. The two representations could be completely different at some point if I'm not careful and when that happens the graphical representation is worse than useless.
This continual syncing between code and pictures becomes burdensome at some point. Unless you can use UML to completely genereate your code this will be a problem (I realize that this is now possible to some extent, but not completely.
There were similar issues in the hardware world when synthesis tools came on the scene: If your representation wasn't synthesizable to hardware then you were doing twice as much work - you had to keep your schematics up to date with your synthesizable HDL code, eventually people wondered why they were drawing the schematic at all and it wasn't long after that that they stopped drawing schematics. The holdouts wanted to hold onto schematics as documentation, but soon people realized that the code itself was documentation.
There is no straight analogy in OO for a flow chart or DFD. But activity diagrams (here, here, and here) 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 one set of things to a picture will map a different set of things to a language. So it is difficult to draw pictures that then create exactly the code (language) desired.
Keep the pictures (activity diagrams) high level but leave the details for coding by hand.
Having said that, I shall now waffle: If you're very good at thinking in pictures, UML does provide some detailed diagrams for run-time aspects of software.
- State Diagrams (here and here)
- Sequence Diagrams (here and here)
- and
- Collaboration Diagrams (here and here)
are all ways to describe run-time state and behavior. I tend to believe programmers generally are better with languages when they need to describe details.Drew
Be careful what you wish for...
Where your treasure is there is your heart also...
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.
http://www.google.com/profiles/malachid
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?
You are probably being serious. Oh, well...
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.
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 scanned napkin? Ask why. Those who want it prettied up are usually those who wouldn't know what to do with it in any format.
Don't overlook the enormous mnemonic value of a napkin. That stain on the side where Jim spilled his drink immediately brings back memories of the meeeting, including all the things that were said but aren't written on the napkin.
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.
Are you coming out of a fucking cave??? What the hell is this bullshit about flowcharts as if we still used them!!! I can't believe this shit!
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
Come on, get serious
If you have a large system or a complicated system, the high level design should be done with flowcharts/activity diagrams.
Of course you very likely won't use it for coding, as a good coder likely does not need that. But often you might want to have a reverse engineered activity diagram from your code. Think about fluctuating staff. New guys comming in, having to extend the software or to fix a bug
How do you do that if you don't have every line of code in your mind?
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
DFDs can eb doen with Activity Diagrams.
... one of the best CASE systems out tehre, for jsut ~200 bucks.
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 miss.
If you are a windows user google for Enterprise Architect
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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 reasonably complex class diagrams to document the major design features of one of our systems. To give an idea of scale, these probably have 10-20 classes per page, and can usefully indicate a few key methods and data members on some of the classes.
I found having a good diagramming tool (in this case, the Pacestar UML Diagrammer I mentioned elsewhere in this thread) to be a great timesaver. It has the key advantage that you can adjust things after you've sketched most of the diagram. That might mean moving classes up a bit so you can fit another layer of a hierarchy in at the bottom, or extending one of the boxes to highlight where a couple of methods are over-ridden, for example. If I start using pencil and paper, I frequently find myself drawing the same diagram twice, once where I expected it to fit, and then a second, better laid out copy when I've seen which parts didn't fit the first time.
A good diagramming tool also produces better looking output, and in a more convenient form which can easily be included with design documentation if you like. That beats a cramped diagram with illegible handwriting scanned into a fixed graphic any day.
Of course, it's taken me several years to find a decent UML diagramming tool. Most of the freebies are bug-ridden and hard to use, and produce horrible output. Actually, some of the expensive ones (Rational Rose being a prime example) are among the worst. Certainly pen and paper is better than these...
If it's going to be in serious documentation, then yes, it should be smarter than a scanned napkin. Good visual layout that reflects the logical structure is half the value of something like a class or state diagram. Without that, you might just as well write it in words or a big table.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Please don't confuse OO with UML. None of the things you mention is necessary for OO (although some variation on things like class diagrams usually arises sooner or later) and some of them are equally applicable to other design methodologies.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Didn't anyone ever tell you that a picture is worth a thousand words?
(Of course, it has to be a good picture to be worth a thousand good words.)
Is it? We usually choose to represent it in a linguistic way, and attempts to use more graphical means have generally turned out pretty badly. However, it's debatable whether that failure was because software design is inherently more linguistic, or whether it just happened that the current linguistic notation was more concise and thus more efficient in use.
Languages are inherently linear. Structured programming (in the sequence, repetition and conditional sense) is a non-linear process: it has forks and loops. Simple functional decomposition is non-linear: it represents a tree of function calls. The relationships between modules in systems are more complex still, with class dependencies in an OO system a prime example.
Today, we happen to project these concepts onto a linear series of grammatical constructions in most languages, but that's only because you can't support anything more than a one-dimensional representation of the underlying structure in a text file. There are other ways, including plenty of research into alternatives to old school plain text representations, and the IDEs and diagramming tools used by many developers today are the current industrial results.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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
How far away from true code is that pseudo code, anyway?
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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 with one another, but DFDs do the job so well that I have never bothered to look into them.
FreeSpeech.org
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.
Don't blame me, I didn't vote for either of them!
You said it, brother.
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 a major shift away from pictoral descriptions toward textual ones in the hardware design world. It's quite relevant.
Drawing schematics (or UML diagrams) is very time consuming and you have to question whether or not you're getting any increased productivity for the time spent - I contend you aren't.
You want other more 'software oriented' objections - how about, how do I grep for a string in pages of UML? Can I write a quick & dirty Perl script to change all of the instances of some variable to another name? Someone else mentioned that most UML tools now export XML, a textual description. Why not just use XML in the first place? How do I write scripts to automate the process of UML creation? You can't beat text when it comes to the ease of parsing, generation and automation via scripts.
p.p.s. And no matter how many valid objections you come up with, management likes to see UML, so it's all pointless.
That's apparently what's driving all of this. PHB's want pretty pictures to look at.
I'm telling you about a major shift away from pictoral descriptions toward textual ones in the hardware design world.
In my company we do a lot of hardware. A heck of a lot. When it comes to programming the chips the do use compilers. But that doesn't do them a damned bit of good when they're laying out a couple hundred chips on a four layer PCB board.
We still use visual diagrams of all sorts on the hardware side. If there's a shift away, then it's definitely not universal.
Drawing schematics (or UML diagrams) is very time consuming and you have to question whether or not you're getting any increased productivity for the time spent - I contend you aren't.
At the level Rational "recommends", you aren't. It's simply overkill. Their view seems to be to design it down to such a low level that you never need to write any code. They also seem to want to to put everything into one humongous diagram. That's ridiculous. The best way to use UML is to keep it high level. Just like writing a function, if a diagram won't fit on one sheet of paper, break it up.
Why not just use XML in the first place?
Because XML is not easily readable by mortals. XML is not an end product, no matter what the glassy eyed disciples at xml.org tell you. It's middle-ware. You render, transform, process, fold, spindle and mutilate XML, but you do not read it. And you certainly don't give it to your partner saying "here's the design".
Rational (among others) seems to think of UML as a code generation tool. They're nuts in my opinion. I, the software developer, am the code generation tool! With UML we're still at the analysis and design phase. We don't start implementing until much later.
PHB's want pretty pictures to look at.
So does everyone else. Well, maybe not you. But most everyone else does. The pretty pictures should definitely not be the only documenation, but they make a fine addition to it.
It's much easier to get a grasp of a complex software construct with a couple of pages of UML then it is with fifty pages of monospaced XML.
Don't blame me, I didn't vote for either of them!
I guess this is a key fissure in computing at the moment.
Tools for designing workflows, like ARIS, don't go together with tools for designing programs, like Rose. At the moment there is a big movement to intergrate service, process and computation in the GRID and Web-Services communities. These discussions are mirrored in the Agent community and OMG's MDA. Languages like BPML4WS do not sit well with activity diagrams and class diagrams.
I think this is because in the workflow world one type of event (a transition) is assumed, where as in the OO world many types of events are possible, but the language doesn't model them. This is a break in the notation that we have. Does anyone have a good solution?
--------------------------------------------- "In the end, we're all just water and old stars."
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 worked on in my career tend to be simultaneously huge, embedded, realtime, persistent, concurrent *and* multitasking- at the same time. And I am *not* just throwing buzzwords at you. I also had to work on projects with 500+ people working on the same product or several versions of the product. In situations like that I have not found flowcharts to be especially useful.
In fact, in that environment, I have found *detailed* documentation to be counterproductive. Sure I can draw the flowcharts and all the other diagrams- but reviewing and reading the multi-inch documents becomes a practical impossibility; even an inch is almost too big. So we have to get rid of the cruft. And flow charts are cruft.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"But if they are now at least somewhat supported, that is a good thing.
But despite your post, I fail to see how it can be done, as a dataflow diagram has completely different semantics from an activity diagram, and just loading some fancy graphics to replace the fancy graphics in an activity diagram won't change that. If you can post a link to an example, I would be very happy. Preferably of the napkin variety, as you shouldn't need a $200 windows-only case tool, just to mock up a dataflow diagram for a simple control system.
For analisys and design the trend today is all about two things:a il/-/0201 571692?v=glancet ail/-/0201 65783X?v=glance
UP - Unified Process
http://www.amazon.com/exec/obidos/tg/det
and
UML - Unified Modeling Language
http://www.amazon.com/exec/obidos/tg/de
I intend to live forever. So far, so good.
A common phrase in the Open/Free software movement, especially in connection with Linux, is "Free as in Beer," meaning you don't pay for the software any more than you pay for free beer. When Linux was first released, software was usually not free any more than beer was free.
If all this should have a reason, we would be the last to know.
The UI and the code will take care if it's self.
My god.
Not only did you break "itself" into two words, but you also added an apostrophe.
There has to be some kind of an award for that kind of mangled spelling.
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?
"How to Do Nothing," kids activities, back in print!
Powdered sugar is too sweet. Most Americans like their food way to sweet. Being an American (and a Dragon), I can say this with confidence. If you doubt me look at the ingredients on a bottle of salad dressing... About Cymry, yes as an ethnic group(my last name is Owen), with a good dose of German as well. I have tried learing Welsh on the Web but...
Meddle thou not in the affairs of Dragons, for thou art crunchy and with most anything.
UML lets you use an Activity Diagram for this as well. Typically activity diagrams are used to document a business process. Activity diagrams explicitly include synchronization and timing information. Sometime that's better than using a DFD as you know that a particular action must complete before its successor starts. Sometimes, it's worse because you may represent synchronization in the model that is simply an artifact of the current process. For example, I worked on cell phone point of sale system that would not let the sales rep take money until the phone activation was completed. This syncrhonization point was't really required for the business process (and actually caused lost sales when the activation system was slow or down), but had crept in through an activity diagram that listed activation as a pre-requisite for billing.
Activity diagrams are actually part of the UML replacement for flowcharts. State diagrams and sequence diagrams (plus, to a lesser extent collaboration diagrams (which are sort of a translation of sequence diagrams mapping objects spatially and time through notation) nostly complete the picture of UML things that replace flowcharts.
Honestly, with exception of the pricey (but apparently bery usable) Rational products, most of the UML editors I've worked with (not counting Visio, which shouldn't come as a surprise) have produced some form of XML document. None of them are exactly human parseable, though. It is nice to be able to CVS the whole thing though.
Perhaps, but add 'test-first' development with unit tests to the mix and you've got an executable spec.
I think we both agree that test-first is an excellent paradigm, and I quite agree that a good set of unit tests help round out any specification. But the fact is that not having some kind of a diagram makes it especially difficult to understand the overall structure of any significant project.
his continual syncing between code and pictures becomes burdensome at some point. Unless you can use UML to completely genereate your code this will be a problem (I realize that this is now possible to some extent, but not completely.
Actually, a historical goal of UML was that it be generated from existing code (i.e. the other way around). The big feature in the UML arena right now is what's called Round-Trip Engineering, which is marketdroid for being able to make changes either in code or in diagram and then sync it up safely.
Basically, there are two cases where UML is most useful. The first is large projects with several developers, since it's very easy to show someone a diagram and let it Just Make Sense, or be able to express overall structural proposals quickly.
The second is starting any project bigger than a dozen objects. Mapping everything out ahead of time can mean big savings in refactoring later (which takes more time even in prototype), and the dicipline inherent to UML means that you can be confident that a well structured UML representation will result in good relationships in the eventual code. Then you've got a rough document of the eventual result that can be updated if it's needed. Otherwise, a literate program with good tests can sometimes be its own specification.
IP is just rude.
Is there any torture so subl
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
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Then I woul dsugest to google for magicdraw (I think nomagic.com).
:D or you got him on the wrong foot.
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 better than any other CASE system I ever saw and it is for less than 1% of the price (comparing it with Rational Rose or Together or Meta Case).
Formal methods in CASE tools have nothing to do with DFDs or model cheking of DFDs. I don't see teh relation. Formal methods in CASE tools usually are bound to OCL (object constraint language). And thats an add on and it does not contradict a DFD or something.
I mean, isn't it formal enough to say: this is a data source, objects of type A, B, C are comming from it, and this is a data sink and objects of type S are going there and this is a process transforming objects A x B to S using C as descider?
I guess your "hired expert" was not such an expert
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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, no matter how much you "stereotype". That was my question.
Ah, ok.
:-), I think at least.
.WMF/.BMP or .GIF images for the stereotypes, you won't see any difference between such an 'activity' diagram and a true DFD.
.. and finally if possible you configure it with constraints to restrict the free drawing options to things which make sense for you or the desired graphical notation.
Understood
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 uses your ints as 'ints' and does not care what "meaning" that int has. That means: the CASE system does not care if you connect an activity to an objct or if you connect an activity with stereotype 'process' to an object with stereotype 'datasink'.
In case you where able to load your own
What is tricky, and depends strongly on the capabilities of the CASE system is: is it allowed to draw a connection from one object with stereotype 'datasink' to an object with stereotype 'datasource'? Or is it allowed to connect two processes (activities) together? In an DFD it is not allowed. A good CASE system like Meta Case can be configured to define a connection in a way that it knows that it is only allowed from process to datasink and from datasource to process. Is your CASE system able to make such definitions, then you can configure it to support EVERY thinkable graphical notation.
Basicly: modern case systems have their build in diagrams configured in exactly that way! All nodes are equal and all connections as well, deep inside of a case system an activity, a class and a use case are all the same. With constraints (who may connect to whom) and tool bars (which image to display for what) the case system vendor configures his diagrams to support the 9 UML diagrams.
Basicly you use stereotypes to define your own language. Its a definition just like a typedef on c++. You agree in your team to use certain stereotypes, which you invent your own, to express something which has meaning to you or your team only. Then you configure the CASE system to support the needed graphics
Very finally and very optional: you anotate your diagrams with tags and more specific stereotypes, generate XMI from it, add a profile and generate source code with MDA or XSLT or velocity or something. But thats of course bleeding edge right now and not a solid method. Look on sourceforge for MDA, there are a lot of tools for that, but they basicly use class diagrams as source and no other diagrams.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Learn some math. EA is $225. Pricing for Rational Rose starts at $1600. That's quite a big gap, but not 100x. "Mentor" my ass.