Student Seminar Report & Project Report With Presentation (PPT,PDF,DOC,ZIP)

Full Version: how to design atm through labview
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Guest

zarmahaiftekhar[at]yahoo.com" class="mycode_email
This page is the starting point into a series of pages that attempt to give a complete example of object-oriented analysis, design, and programming applied to a moderate size problem: the simulation of an Automated Teller Machine. I developed these pages in the belief that students would benefit from seeing a complete example of OO methodology applied to a single problem. Since then, I have developed a similar-style solution to an even simpler problem: maintaining a very simple address book.

Beginning with a statement of requirements, the process proceeds through analysis, overall design, and detailed design and implementation, culminating with some suggestions for maintenance. (Testing is left as an exercise to the reader :-).)

Analysis is done by identifying the use cases and detailing a flow of events for each. Also, an initial set of functional test cases is specified, to serve as a vehicle for checking that the implementation is complete and basically correct. Analysis culminates in identifying classes implied by the use cases, and documenting them using an Analysis Class Diagram. (The Statechart diagrams done under design are also, in part, analysis tasks. In OO, the line between analysis and design is not always a sharp one.)

Overall design begins by using CRC cards to assign responsibilities to the various classes. The static structure of the design is summarized by means of an overall Class Diagram. Then the dynamic aspects of the design are developed, using State Charts for the major controller classes, plus an Interaction Diagram for each of the main use cases.

The detailed design is developed by spelling out the attributes and methods for each class, using a class diagram for each class with all three "compartments" fully filled in. A package diagram is used to show how the various classes are groupled into packages. Each class is then implemented in Java. The code page contains links both to Javadoc documentation for each class, and to the complete source code. Also included are a main class, which allows the simulation to run as an application, and an Applet class, which allows it to be run as an Applet. (This illustrates how the same basic code can be designed to be used either way; the application was used for most of the initial development work, but the Applet is accessible to anyone over the web).

The Executable Applet version can be loaded and executed from within any web browser that supports at least JDK 1.1.x.

The Maintenance page discusses ideas for possible changes to the system, each of which would require changes to multiple documents, not just the code.