Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
In visual programming, there are many events which support our application tasks. So, along with user defined processes, should these also be in flowchart or not?
What about the constructors of classes, are they supposed to be shown in flowchart or not?
In short, a flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows.
You may also think of a flow chart as a process flow of application logic while connecting components in some type of flow of events.
What about the constructors of classes, they supposed to be shown in flowchart or not ?
Well class design is not done by means of flow chart. Generally a UML diagram is created to present class diagram structure or high-level application design.
The Wikipedia article covers this pretty well. Look under building blocks; if it's not there, a flowchart doesn't cover it.
Flowcharts are mostly meant to illustrate a process that embodies an algorithm (a recipe for solving a problem). The flowchart illustrates the procedural steps that the computer would take to solve the problem.
Generally speaking, all Inputs (via I/O box), Outputs (via I/O box), Processings(via Proceesing box) and Decisions (via Diamond box) should be reflected in your flowchart.
Talking about events, they can be depcited somewhat via the diamond box if you like. For example:
if (user/system does that) then
do this
else
do this
For constructors, you need to use Object Diagram. As constructors are class methods whose sole purpose is to keep the object in a valid state when instantiated.
Not to intentionally be a contrary, but in answer to the question:
"What types of processes have to be reflected in flowchart?"
I think the answer is none of them.
Flow charts have been around a long time. For developers, they are time consuming to produce, particularly in the quantity that would be needed for a commercial scope project. They also have the disadvantage of going stale pretty fast once developers start coding to them and integrating logic discovered during implementation and test.
In casual conversation with Dr. Bill Curtis, who was one of the authors of the SEI CMM 1.1 and a person with some background in software process and psychology (a PhD), he said to me and others that our diagrams depend on people being high-spatial to understand them, but people who were high-spatial could pretty easily form a mental picture from text representations of software like pseudo code.
Most of the object oriented methods advocate leaving behind flow charts and also data flow diagram as artifacts of structured programming and even pre-structured programming. More useful are techniques like use cases annotated with alternative flows. Use cases tend to start with a nominal flow that may describe some conditions, but not much branching of the control flow. Branching is covered in alternative cases, and typically references the nominal flow for brevity, accentuating only the differences. Another good reason to consider use cases instead of flow charts is that they can easily include as much text as is needed for clarity, although all but the shortest text can cause problems with gracefully sliding text into flow charts, and combined with routing and other manual manipulations, can eat up a lot of time, sometimes with good benefit, sometimes without.
