-3

I'm not quite sure of the proper flowchart notation for returning an object/value from a function (I'm also looking for some quick tips on proper flowcharting notation in general, if anyone notices any glaring issues).

Key key = FindKey();    
Ferrari f355 = Valet.GetCar(key);    
f355.Go();

enter image description here

Improve this question
2
  • 1
    Who are you talking to? Did someone delete a comment? Anyway, flowcharts are not really designed to do this. Perhaps you're looking for a "Data Flow Diagram?"
    – Robert Harvey
    Dec 9 '16 at 21:49
  • @RobertHarvey Hey R.Harvey, I was talking to the muted downvoter... Thanks for the tip, I'll look into over the weekend. Cheers.
    – samus
    Dec 9 '16 at 22:01
2

Flowcharts represent flow of control, not flow of information. Flowcharting formally captures steps and the linkages between them that describe the transfer of the flow of control that are often based on decisions: in particular, conditional branches and loops.

Flow of control is about what is done or happens next, and (sadly) not about the required data to perform that step.

According to Wikipedia, there are some extensions for the flow of data; however, they are basically limited to documents and files.

Generally speaking, state is poorly represented in flowcharting; there is virtually no notion of data, variables, scopes, lifetimes, or types. So, data (and metadata about that data, such as allowed or expected types) is mostly documented informally with human language description in the text within individual steps of the flowchart.

Input & Output in flowcharting is meant to indicate communication with another independent and top-level process (even if it is just a later running copy of one's self). As such this communication is about reading/writing to disc or to a network.

A getter does not qualify as input or output, which is to say communication with another independent process, so I think that is out. I don't think they even had getter's when flowcharting was first applied to software design (circa 1950).

You might look in to UML.

Improve this answer
6
  • 2
    You might look in to UML. - specifically a data low diagram
    – Stephen C
    Dec 9 '16 at 23:02
  • Your clear and concise articulation of the subject matter really helps in illuminating the long and arduous path to proficient software documentation set before me. For this I humbly thank you.
    – samus
    Dec 12 '16 at 14:37
  • So are flowcharts adequate for documenting function logic at all? Can they abstract a function's logic with any useful meaning? I have no problems using data flows, I'm just curious.
    – samus
    Dec 12 '16 at 14:54
  • 1
    As flowcharts are weak on state, they are not adequate for fully documenting a function's logic. Yes, sometimes they can abstract usefully, especially for critical decision points, such as to go left vs. right or to loop. Some might argue that in today's world, source code is the most appropriate and up-to-date documentation! Others would say that it is the pre/post conditions (e.g. how to properly use the function) that is most important, along with, say JavaDoc style description.
    – Erik Eidt
    Dec 12 '16 at 16:51
  • 1
    Also, you might have a look at BPMN & BPEL. While these are meant to be used at a business level, they are more process-oriented, e.g. have control flow, decision points, etc.. I'm not a big fan of describing business logic in terms of control flow (I like services, roles & responsibilities), but their modeling & language is richer than flowcharting.
    – Erik Eidt
    Dec 12 '16 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.