A very important part of computer programming is making sure that everything is organized. A good program has to be made using System and Program Mapping tools. A very common mapping tool to help keep all the work organized is a Structure Chart. Structure charts are directly related to top-down modular design. It looks like a stack of squares that all represent the different modules in the system. Allow with the squares describing the different modules there are also lines that connect the squares together. Used as a design tool they can also help with solving a complex problem my breaking the program down into smaller parts. These smaller parts are easier to understand, and the easier they are to understand the easier it is to find a solution. Structure charts are like blue-prints for computer programs. Structure charts so the system flow of the program as well to show what each individual module does and how it is directly related to the overall operation of the program. Flowcharts are another common organization and mapping tool that is used by computer programmers. As opposed to a structure chart, a flow chart can be used to document the various steps in any given program. Structure charts puts the various modules into a tree structure. Flow charts will normally just be in top-down format and does not show the different modules, just the different processes in a program. Both flow charts and structure charts are great organizational tools and can make it easier to make a smooth running program.
Using a structure chart in real life would be just like an architecture using a blue-print for building a house. Using a blue-print can be easier than just winging it, or even just reading how to build something. It is always helpful to have a visual aid while trying to make something, no matter what it is. Using a blue-print or a structure chart can eliminate much of the stress from a large project by breaking each part of the project into smaller, more manageable projects. Having structure is important when dealing with life. It is never easy to just guess the next step or get over stressed trying to figure out how to address a problem. My father always use to tell me to take things one step at a time. When you can find the solution to a problem it is best to take a step back and analyze the whole picture. Doing so has also taught me that it is better to take a problem little pieces at a time instead of taking the whole thing at once. When we can eliminate the stress from a project it is so much easier to solve a problem the first time, with little to no mistakes. Stress causes the mind not to focus clearly and as a result we can make mistakes. Having structure in our lives makes taking on the day to day problems a lot easier, and it is a practice that I believe everyone should get involved with.
At first glance, I am admittedly not a fan of the format of your post. It is posted in as one giant paragraph with no other formatting. It would be nice if you could format your post as multiple paragraphs or even find occasion for bullet points to occur. But the content of your post seems very straight-forward and to the point.
ReplyDeleteI can definitely see the benefit of using a structure chart to chart out the individual modules I would have in a given program, as well as the benefit of using a flowchart, which can help define the exact flow of logic within a program. Using both together can probably yield good results when planned together correctly. Rather than starting from scratch and jumping in head-first, you have something to go by, a plan of action to back up what you are doing. In practice, I see the full time staff in my office take great advantage of this methodology. I am not sure how it translated into practical execution since all I can see from my end is the method taking up time to produce the plan rather than getting to the program from the get-go, but since they continue to use it, I am sure it does save time in the end. My supervisor uses it mainly for networking, which seems pretty important for understanding the intricacies of switches, routers, servers and where all the cords link up to. But the other full time programmer uses it regularly for his larger projects which involve many elements. Personally, I usually forego using such a scheme since I understand the way my program will be put together pretty well and can see it through to public use just fine. But if I wanted to present to someone how a program works without being overly technical, one or both of these methodologies would definitely need to be used.