The condition in your flow chart is incomplete



This is my first flow chart but I have modified the conditions
View attachment 196252

My question is whether my flow chart follows the given table or not. If not then where it become fail?

Edit: The first priority is to make the correct the flow chart After that i can think of cleaning it as @MrChips said

There are several issues with this, most of which have already been pointed out.

In terms of it matching the provided table, there are the following issues:

The table does NOT say that a score less than 0 or greater than 100 is a fail while your flowchart does.

You still only have a single path leaving most of your decision boxes. The whole point of a decision box is that you make a decision about which of two paths to continue the journey through the chart. When you hit the second box with a score of 73, what happens? The flowchart doesn't say, so the reader has to guess. Since this is supposed to be translated into a computer program, that's a really bad thing because computers don't do guessing games well.

Your first decision box is not well-defined. Are you asking, "Is (Score >= 30) OR (Score <= 100)?", or "Is (Score >=30) AND (Score <=100)?" ? Assume someone else is going to be turning this flowchart into a program and don't make them have to guess what you probably meant.

Let's pick a value and see what happens according to your flowchart. Choose Score = 35. The first decision is Yes and so you execute the box "Pass". The second test passes and you execute the box "Third division". The third decision passes and you execute the box "Second division". The fourth decision passes and you execute the box "First division". Finally, the fifth decision passes and you execute the box "honours" and then Stop. Is this really the behavior you wanted?

Even after you fix this, your current basic structure will do something for a Score of 45.5, but will it do the right thing? What does the table say it should do? It doesn't. That is an unspecified outcome. This is a shortcoming of the table, but if your goal is to make your flowchart be faithful to the table, then you have to honor that shortcoming.

 

The original specification has scores <0 or >100 as being undefined. The TS's original flowchart has them as being FAIL. They should be left as undefined or a reasonable supplement to the specs should be made and documented.

I'd argue that pointing out the inconsistency to the TS is more important than pedantic adherence to the spec, the latter being a prime suspect in plane crashes and similar disasters.

My question is whether my flow chart follows the given table or not. If not then where it become fail?

No, for example a score of 35 -> honours.

 

I have prepared this flow chart And I think this solves the all problem

A flow chart won't magically solve a problem in an efficient manner; that's your responsibility. The algorithm you've chosen isn't very efficient. You should try to minimize the number of times you check a score.

Plus your flow chart doesn't make any sense. The decision boxes need two branches.

 

I have the feeling that you are looking at "flowcharts" as an end or a product. In reality, they should be a procedure to help you reach an end. Maybe it would help avoid the sort of errors pointed out in post #19, if you printed out your flowchart and then went through each step.

When I do a flowchart, I have a difficult time detecting all the errors and/or unaddressed options while it is on my computer screen. I print it out and frequently take a break. Then return with pencil and trace through every step. I am far more likely to find things that need to be changed than to find the chart acceptable at that stage.

Excellent observation and good advice.

 

When I do a flowchart, I have a difficult time detecting all the errors and/or unaddressed options while it is on my computer screen.

I print programs, flow charts, schematics, PCB layouts, documents, etc so I can review them later with a fresh perspective without having to be at a computer. A paperless world wouldn't work for me.

 

What do you think about it?

 

The flow-chart was already given to you on post #13.

 

I'd argue that pointing out the inconsistency to the TS is more important than pedantic adherence to the spec, the latter being a prime suspect in plane crashes and similar disasters.No, for example a score of 35 -> honours.

The inconsistency was previously pointed out, both by myself and others. For instance, I stated, "The original specification has scores <0 or >100 as being undefined. The TS's original flowchart has them as being FAIL. They should be left as undefined or a reasonable supplement to the specs should be made and documented."

Here I was responding to the specific question, "My question is whether my flow chart follows the given table or not. If not then where it become fail?" and I prefaced my response very specifically with, "In terms of it matching the provided table, there are the following issues:"

The TS, per his original post, is attempting to improve his ability to construct a flowchart, in preparation for constructing a program, that implements the logic embodied by a table. Hence, in this context, being able to faithfully adhere to the table is of central importance from two perspectives. First, being able to identify and implement the subtle and fine details of a spec is critical to faithfully deal with those details, especially as they pertain to corner cases. Second, being able to identify the subtle and fine details in the spec is critical to identifying its shortcomings and inconsistencies so that they can either be addressed by the people that developed the spec or so that reasoned and documented deviations from the spec can be implemented. I think that's far better than just ignoring them and implementing something that is somewhat close to the spec and hoping that whatever the system does in the case of the overlooked inconsistencies happens to work. That's also a prime suspect in plane crashes and other disasters.

 

What do you think about it?

View attachment 196268

There should only be one arrow entering a given box. Your "Program Stop" box has two arrows entering it. You should deal with this the same way you dealt with it numerous other places by having the arrow leaving the "honours" box go to the arrow coming down the right and side before it gets to the "Program Stop" box. This is a fairly minor issue as no one should have any problem determining what you mean.

You still have the same problems I pointed out previously.

Put your finger on the Program Start symbol and then follow your flow chart and do exactly what it says from beginning to end. Do not lift your finger off the paper and keep in always on a line except when you enter a box and then move to an exit arrow from that box. Repeat this for choices of Score that should result in each possible output. What happens when you choose a score of 35?

 

I have the feeling that you are looking at "flowcharts" as an end or a product. In reality, they should be a procedure to help you reach an end. Maybe it would help avoid the sort of errors pointed out in post #19, if you printed out your flowchart and then went through each step.

I understand that the flow chart helps in understanding things. If I can fix the problem in the flow chart, then I will not have much trouble writing the code.

I have created a new flow chart in post 26. After verifying several times I found that this is correct, so I posted it

I am trying my best not to make mistakes But still i make a mistake.

 

A properly drawn flow-chart ought to be a working blue-print, just like a building construction blue-print.
Once you verify that the flow-chart is correct, it makes writing code straight forward.

 

I have created a new flow chart in post 26. After verifying several times I found that this is correct, so I posted it

Does a score of 105 pass or fail? Doesn't a logical "and" return a false if one element is false

 

I think that's far better than just ignoring them and implementing something that is somewhat close to the spec and hoping that whatever the system does in the case of the overlooked inconsistencies happens to work.

Yet your approach was to ignore the boundary condition as "undefined" rather than demand the requirements be amended and codifying the problem to ensure it is corrected. Google "Defensive Programming".

That's also a prime suspect in plane crashes and other disasters.

But it was I that objected to the inconsistency and you suggested that the unexpected input should not be failed specifically because the spec said so, or rather, didn't say not to.

 

What do you think about it?

This is mostly what you implemented, but continues until all scores have been checked:

 

You still have the same problems I pointed out previously.

@WBahn
Sorry I did not read your post earlier, because I was making a flow chart.

I have prepared the specifications given in table myself. You are right, there is problem in given specification

It would be better to help me to make a better specification So that my chances of making a mistake will be less

I have noted your points

*The table does NOT say that a score less than 0 or greater than 100 is a fail while your flowchart does.
-> invalid number
* Even after you fix this, your current basic structure will do something for a Score of 45.5
-> flot data type
*"Is (Score >= 30) OR (Score <= 100)?", or "Is (Score >=30) AND (Score <=100)?" ?
-> (Score >= 30) OR (Score <= 100)?" False

Is a better specification than previous ?

Student Status	Score in Exam
Invalid score	less than 0 or greater than 100
Fail	0-29
Pass	30-100
Third Division	30-45
Second Division	46-65
First Division	66- 75
honors	76- 100

I will try to fix the problem I'll take my time and come back with a new flow chart

 

Yet your approach was to ignore the boundary condition as "undefined" rather than demand the requirements be amended and codifying the problem to ensure it is corrected. Google "Defensive Programming".
But it was I that objected to the inconsistency and you suggested that the unexpected input should not be failed specifically because the spec said so, or rather, didn't say not to.

The purpose of the exercise is not to implement a useful program, but specifically to be able to develop a flowchart that matches a table. That is the context of the discussion -- does the flowchart match the table, period. The table could be random things drawn from a fantasy world, or it could be deliberately misleading precisely for the purpose of seeing if people will fall back on the very-human behavior of subconsciously applying their own interpretation based on what they think it should be or was meant to be, or it could be an oversight in the table. In all of those situations, the proper first step is to be able to recognize what the table actually says, not what we would like it to say. In the real world, and as much as possible in the academic world, of course clarification should be sought where possible. But in academic exercises -- such as text book or online problems -- this is often not possible. As this is basically an academic exercise, the advise I gave was within that framework in which the information you have is the information you have, so you either go with strict compliance or you deviate from it and document it (and even if you comply strictly it would be good to still document the inconsistencies and/or missing specifications).

 

@WBahn
Sorry I did not read your post earlier, because I was making a flow chart.

I have prepared the specifications given in table myself. You are right, there is problem in given specification

It would be better to help me to make a better specification So that my chances of making a mistake will be less

I have noted your points

*The table does NOT say that a score less than 0 or greater than 100 is a fail while your flowchart does.
-> invalid number
* Even after you fix this, your current basic structure will do something for a Score of 45.5
-> flot data type
*"Is (Score >= 30) OR (Score <= 100)?", or "Is (Score >=30) AND (Score <=100)?" ?
-> (Score >= 30) OR (Score <= 100)?" False

Is a better specification than previous ?

Student Status	Score in Exam
Invalid score	less than 0 or greater than 100
Fail	0-29
Pass	30-100
Third Division	30-45
Second Division	46-65
First Division	66- 75
honors	76- 100

I will try to fix the problem I'll take my time and come back with a new flow chart

If you specify the constraint that all scores are integer values (stored as integers), then this should suffice. I would still say that a better table would be something like:

Second Division More than 45 but not more than 65.

 

I do not agree that the specification is incomplete. It specifies precisely which category each score will be placed in for every value from 0 to 100.
As a result, any score below 0 or above 100 should automatically be rejected because it does not belong in any category.

 

I do not agree that the specification is incomplete. It specifies precisely which category each score will be placed in for every value from 0 to 100.
As a result, any score below 0 or above 100 should automatically be rejected because it does not belong in any category.

So what category does a score of 45.5 belong to?

 

So what category does a score of 45.5 belong to?

I see what you mean. It is obvious that the values must be integers to fit the requirements but it is not stated.