Steps Used in Designing Building Access to Databases - Report Example

Introduction The aim of the paper develop a program that will be used for testing whether the story is fake or real, arrange it in the table form and stores it. The program will be able to manipulate stories by counting, recording in table with columns News item, fake/real and user choice within a reasonable time as well as monitor the user choices. A quick and effective java program can test the stories and that too quickly and by sorting the stories table. It should be able to help users of the stories to find real news that is being accessed from the database. It should take them through the site with easiness to find the materials rather linking them to news. However it should be able to detect fake news retrieved by users from the database. Steps used in designing Building access to databases Identification of Audience – the designing begun by identifying audience that was going to use the program. This ensured that the designed program concentrated on audience of news collections. The main aspect in the identification of the audience and target site was to find the problem. This stage facilitates focus on the right problem to come up with the right answers Understanding user’s problems to be solved – in this case the users of news database were interested in retrieving, sorting, creating and identifying real news Generating Real Solutions - This part entails generating real solutions, necessitates brainstorming. This stage obliges the entities to think outside the box and come up with all manner of ideas they can think off. This stage is very important because it grants the opportunity to come up with possible solutions. Preparation for action -The final part in the process calls for an entity to take action. At first, the entity should seek to reinforce and enhance the top ideas generated from step two. This should be followed by the creation of a standard to assess the ideas for their effectiveness. The standard should be applied to the top ideas to come up with those likely to solve the problem and ideas, which are easy to implement. Finally, the one should accept the findings in that one should decide on what is to be done to realize a matured activated solution. This step involves the goal setting exercise which is an important part in creative problem solving. Gather – this involves the gathering or related data that is suitable metadata element set from source documents. Some of the strategies discussed such as indexing use spider and robot to gather necessary materials on the greenstone collections. Robots are programs that retrieve hyperlinks that are linked to files accessed as well as have the ability to load into a database and index them through a formula. The indexing formula varies from database to database. Based on a request given by the user, the database is searched. Robots follow different methods for gathering information from web pages which is different from other search engines that indexes the whole file found in a web to the database of greenstone collection. This is what is known as full-text indexing and most search engines are known to have full-text databases. Design - design should address all issues for successful implementation of the database system by stating the collection configuration such as Indexes Create - These procedures are taken into consideration to create collections that are specifically useful for the target users. The approach could be considered complicated at some point as creating these collections involve too many technicalities that not all are ready to take into consideration. Format- this involves creating appearance of the Collection Build and Preview – Designing and previewing the created Collection Challenges in implementing Like most systems, this has its own challenges like inability to perform its functions properly by not retrieving news from database and manipulating it. This happens even there is a comprehensive search by the access program where a small section of data will be produced. Therefore the designed program should be having ability to select required files carefully and rank them in order of real or fake, so that the fraction of the news that is listed is more meaningful. The program will refresh the stories by revisiting them once again to detect any changes that might have occurred and required full attention. Debugging Tips and Techniques The most powerful weapon in your arsenal against bugs is your ability to reason. There are also some hands techniques and tips that can reduce the time spent debugging. Try to come up with the smallest amount of code that still exhibits the error. You can do this by removing calls to methods that are unnecessary and removing statements that should have no bearing on the problem. Anything you can do to reduce the complexity of the code you are debugging can be helpful. As you are removing code, you probably want to periodically run the code to make sure the bug is still there. If it goes away, you have discovered valuable information that you can use to reason about the cause of the bug. As you remove code, be sure to retain a copy of the original code. Along these same lines, you should produce the smallest inputs that still cause the bug. If the program is interactive, try to find the shortest sequence of commands that cause the error to occur. Knowing the precise input that causes the problem is useful information. Stabilize the error. Bugs that occur sporadically are some of the hardest to track down. If the bug does not happen consistently, work to make the bug appear reliably. If the bug is a hard one to track down, you will probably be running the program over and over again. In this case, you want each run to be productive. How you make the bug appear reliably depends on the program; you will have to be resourceful. Here are some common techniques programmers use, depending on the situation determine the exact sequence of inputs or the precise conditions that cause the bug to occur. If you are using a random number generator, make sure the seed is set to the same value on each run. If the bug only occurs after the program has been running a long time. Figure out ways to simulate that behavior. Perhaps the bug only occurs when data structures grow large. Simulate this behavior by writing a function that builds large dummy data structures. Call the function at the beginning of the program to simulate the effect of the program running a long time. Dump the state of the program periodically. That is, print out key values and data structures. Use this last “state” information you’ve collected to initialize the program so it fails quickly and reliably. Locate the error. Try to determine what function or section of code is causing the problem. To do this, Print data values and observe at what point in the execution incorrect values are produced. It also helps to try different input values and observe the effect on the code. Sometimes with the right input you can “triangulate” the location of the error in the code. Figure 13.5 illustrates the process of triangulating the location of a bug. Locating a bug via triangulation often requires running a handful of test cases to narrow the location of the bug down to a region of code small enough to be helpful. The problem is that each test set may identify a large region of code. Consequently, more than two or three test cases are needed to zero in on the location of the bug. Recognize common bugs. Some common bugs have specific symptoms. Knowing the symptoms of commonly occurring bugs can help you identify them quickly. A common bug is over subscripting or under subscripting an array. Java throws an array index out of Bounds Exception if an array is improperly accessed. A common cause of an Array Index out outBoundsException an off-by-one-error in a loop- the loop iterates one time too many, or the loop starts off with the index initialized improperly. Dereferencing null is another classic bug. This bug occurs when the program attempts to access an object through a reference variable and the variable has value null. Again, java will throw a nullpointerException when a program attempts to dereference null. The real issue, however, is however, is why is why is the pointer null. Sometimes the variable is legitimately null, and you just forgot to guard the statement dereferencing the variable with an if-statement, other times, you have a live bug that you need to remove. In these cases, using the scientific method of debugging to locate the bug is the best course of action. Recompile everything. Modern IDEs are extremely useful, but sometimes they can get confused. If you have been making lots of changes to the code looking for a bug and the code is not behaving the way you think it should, or change you have made do not seem to be having an effect, rebuild the entire project from scratch and rerun the code. Gather more information. If you are stuck and cannot seem to understand what’s going on, generate more data. Some standard actions taken by experienced programmers include running different test cases, using the debugger to observe the program’s flow of execution, printing out intermediate results, and displaying data structures. You need to be selective and only print as much as you can reasonably digest. Sifting through mountains of data can be like searching for a needle in a haystack. Pay attention to the compiler. Modern compilers are very good at detecting certain types of errors. However, they tend to be conservative and sometimes produce warning messages that end up being spurious. When you are searching for a bug, it’s a good time to pay attention to all those warning messages you have been ignoring. If the compiler reports an object is used before being set, then that problem is something worth investigating. Many compilers allow the programmer to control the level at which error and warning messages are issued. Setting the compiler to the strictest level can sometimes yield information that is helpful in searching for a bug. Fix bugs as you find them. It often happens that when you are looking for a bug, you discover another bug. This bug seems unrelated to the bug you are trying to find. It is tempting to put off doing something about the bug just discovered since you are in the middle of tracking down the original bug. You do not want the trail to go cold. Generally, it is good practice to fix bugs as you find them. The bug you just found could be related to the one you were originally trying to find. Fixing this bug, could make the other bug go away. This phenomena happens quite often. On the other hand, if you are sure the newly found bug is unrelated to the bug you were originally searching for, and then it may be worthwhile to keep searching. Take a break. Sometimes you get nowhere with a bug despite spending hours trying different strategies to locate it. While perseverance is a valuable programmer trait, knowing when to take a break and get away from a problem is also valuable. Experienced problem solvers know how important it is to get away and does something that lets the mind wander jog, listen to music, take a walk, and stare out the window, so on. As you relax, the solution to the problem might just come to you. Most experienced programmers have war stories about bug hunts. A common story is the “debugger`s epiphany.’’ The story goes something like this. Sally has been hunting a particularly nasty bug for days. None of the tried-and-true techniques for finding the bug have worked. Sally decides to take a break and hit the hills for some mountain biking action. When sally is flying down a hill with trees whizzing by, the last thing she is thinking about is the elusive bug in the web browser. After a great afternoon, sally heads home for a shower. As she showers, she starts to think about the bug again, and it hits her- the solution to the browser problem suddenly becomes crystal clear. Sally heads to work to run an experiment to validate her hypothesis, but she’s confident she’s got it. Stories like sally’s are common. Of course, the best stories always have the programmer doing something unusual when the epiphany occurs! Think outside the box. It is very easy to get locked into a particular way of looking at or attacking a problem. If you are getting nowhere with a problem. Try thinking outside the box. Try something unusual or new that you have not tried before. For example, do the opposite of what you have been doing and see what happens. Debugging is an important part of the programming process. As you gain experience with programming, you will no doubt develop your own personal style of debugging favourite techniques, tricks, tools, and so forth. You will also learn to use a source-level debugger. A source-level debugger integrated into a modern IDE is a powerful tool for tracking down bugs. However, the most important point to remember is that the key to effective debugging is to follow a disciplined process. Together, disciplined testing and disciplined debugging ensure that high-quality software is delivered on time and within budget.` Read More