Unix commands
- 1. UNIX COMMANDS is -l : lists your files in 'long format', which contains lots of useful information, e.g. the exact size of the file, who owns the file and who has the right to look at it, and when it was last modified. cp filename1 filename2 : copies a file rm filename : removes a file. It is wise to use the option rm -i, which will ask you for confirmation before actually deleting anything. chmod options filename : lets you change the read, write, and execute permissions on your files. The default is that only you can look at them and change them. u - User who owns the file. g - Group that owns the file. o - Other. a - All. r - Read the file. w - Write or edit the file. x - Execute or run the file as a program. Tool: http://ss64.com/bash/chmod.html cd dirname : change directory. you basically 'go' to another directory, and you will see the files in that directory when you do 'ls'. you always start out in your 'home directory', and you can get back there by typing 'cd' without arguments. 'cd ..' will get you one level up from your current position. pwd : tells you where you currently are. grep string filename(s) : looks for the string in the files. This can be useful a lot of purposes, e.g. finding the right file among many, figuring out which is the right version of something, and even doing serious corpus work. grep comes in several varieties (grep, egrep, and fgrep) and has a lot of very flexible options. Check out the man pages if this sounds good to you. mkdir dirname --- make a new directory
- 2. LIFE CYCLE The Waterfall model (proposed by Royce) each activity completes before the next activity starts There is no repetition of activities. The waterfall model is often used to plan activities within activities of more complex models. there is often a requirement to check that the outputs of each activity not only satisfy the input requirements but that the outputs also satisfy the ‘real-world’ requirements as well As can be seen, the activities still progress from left to right, with each activity ‘signed-off’ before the next commences. But now there is validation of each stage of the implemented system.
- 3. Rapid Prototyping diagram Methodology - SSADM (Structured Systems Analysis and Design Methodology) a The main premise behind prototyping is that users don’t know what they really want. The aim is to provide early ‘models’ of the final system which let users explore their needs better than would be possible just by talking to an analyst. There are two approaches to prototyping: • ‘throw-away’ prototypes, where early prototypes do not contribute to the final product • ‘evolutionary’ prototypes, where early prototypes build up into the final product - this is the most common form of prototyping today The core of prototyping is the Prototype Iteration activity, where repeated prototypes are developed, evaluated by users and refined Prototyping has advantages in that the user feels (or should feel) more involved in the development process Also, based on the idea that it is easier to fix problems early in the development process, additional attention is given to the earlier activities (those building up to the first prototype) - this leads to lower maintenance costs. An example given by Connell & Shafer suggests that something like 25% of the lifetime costs of software might be saved by adopting a prototyping approach. Prototyping allows users to see these errors at an early stage, thus allowing quick and cheap correction. Another rather significant problem is that performance of the final product may not be satisfactory, due to the piecemeal way in which it is constructed Rapid prototyping methodology - DSDM (Dynamic Systems Development Method)
- 4. Testing Unit testing • testing and verifying single program units Integration testing • verifying the interfaces between units Regression testing • ensuring that changes do not affect existing parts of the system Systems testing • ensuring a system meets its objectives Acceptance testing • ensures the system meets user requirements -------------------------------------------------- “black box” • the tester only tests that the outputs are correct (as per the requirements specification) for given inputs “white box” • examine the internal detail of units to verify that all the ‘code’ is functioning correctly Integration testing links white and black box testing ------------------------------------------------- Black-Box Testing So, if we can’t test every possible list, how many do we need to test? We could take a statistical view of the problem, that by testing so-many lists we achieve such-and- such a probability of the module functioning correctly for any lists. Also we have to know things like whether the input list can contain duplicate values. In this case we might build ‘test cases’as follows: • a zero-length list • one element lists • lists of length = a power of 2 (this, of course, assumes that we know something about how some sorting algorithms work!) • lists of length = a power of 2 minus 1 Thus a major drawback of black-box testing is that it is usually impossible exhaustively to test a module ------------------------------------------------------------------------
- 5. White Box Testing If necessary, we could trace the execution of program statements during testing to ensure that every statement has been ‘exercised’. Then we could design tests that would specifically target statements not normally executed. Estimates of the percentage of actual ‘bugs’ detectable by testing varies between 50% and 70%. -------------------------------------------------------- Integration and System Testing Tested modules are added to the system one at a time - if necessary ‘stubs’ or dummy modules are used to simulate modules not yet added. Eventually the completed system emerges and can be subjected to testing to ensure that it meets specification and (easily forgotten) user requirements. ------------------------------------------------------- Black-box testing in the context of the assignment is making sure that the pages and any cgi/php scripts work when accessed through the browser -obviously this is vital as it is what will be seen by the user. -------------------------------------------------------- CGI Internet "conversations" between two computers take place between a server and a client. Using the http protocol web pages are displayed on the client. CGI (Common Gateway Interface) programs run on the server (server side). 1. Form displayed on client 2. User enters data and ‘submits’ form to server. Data from form transmitted from client to server 3. Specified CGI program starts executing and collects transmitted data 4. Data processed and output page generated by CGI program. CGI program then terminates 5. Output page transmitted from server to client and displayed
- 6. Note that there are two components to the interaction • An original (usually blank) form (loaded as a normal webpage or generated by a program) • A CGI program (called from the form) Creates a web page ‘on-the-fly’ for return to the client browser by writing appropriate HTML code to the program output. What happens when we start a browser (eg. IE) and request an off-site link? • The name of the remote server is resolved to an IP address using one or more DNS(Domain Name Server); • The remote server is contacted on a special port (default 80) using the http protocol; • The server verifies the client has legitimate access to the data and then accesses and transmits it; • The client browser decides how to treat the document (html, audio, video etc) – often with the help of plug-in software How is the Client/Server operation modified for CGI Programming? • The server provides the end user (client) with a blank HTML FORM • Via a browser (usually) the user enters text or makes preferences/selections • The user defined data (and other "hidden" information) is sent back to a CGI program on the web server • The program processes the data and writes HTML (with a MIME header) back to the server - extra header information is added if required - and the whole is sent to the client Values passed from forms back to CGI programs are URL Encoded ------------------------------------ Two methods, GET and POST exist to communicate between the client and server. GET is used to retrieve data from the server – the form data sent to the server is encoded as name=value pairs in the URL e.g. POST method is used to send information to the server – the form data is encoded within the body of the message passed back to the server – the CGI can receive this via the standard input ‘file’ STDIN.