1. Unit 251 Summary  Requirements may be represented in itemized format or in visual modeling (UML). Once the complete set of requirements are in our hand, we move on to the design phase.  The steps of the object-oriented design process in this chapter are 1.Identify the classes and objects. 2.Describe the object collaborations and the classes. 3.Design the class diagram. 4.Sketch the user interface.

2. Unit 252  Focusing on the nouns and verbs of the Requirement statements will help you to identify the classes, responsibilities, and collaborations the program must provide. These are recorded using CRC cards, which also list the data attributes of each class. Data is transferred from CRC cards to class diagrams, which are more convenient to reference during subsequent software development activities.  The final step of the object-oriented design is designing the user interface. The user interface is important because it is visible to the user.  From the class diagrams of the design phase, the corresponding Java templates are generated. From the user interface design, the corresponding html templates are written down. These are the outcome of the design phase.  During the Implementation phase, these Java and html templates are coded with proper comments and documentation. These programs are tested using the techniques of unit testing. Now the modules are ready. Summary (cont ’ d)

3. Unit 253  During the integration phase, these modules are integrated into a product. The product is tested using the various techniques of integration and system testing. Now the product is ready for installation.  During the Deployment and Maintenance phase, the product is delivered to the customer with the user’s manuals.  The user training is an important part of this phase. Then the software is maintained until the end of the contract. Summary (cont ’ d)

4. Unit 254 Exercises  Here we list the requirements of three projects.  They are similar to the one we discussed as a case study.  These projects are: 1.Banking 2.Train ticket issuing system 3.Tic-tac-toe.  It is a good exercise for the students to implement the projects applying the principles of software engineering.

5. Unit 255 1. Banking  You have been asked to develop a banking system for M&P Banking.  Hardware and network portion has already been bought.  You need to write software to manage savings and checking account transactions as well as ATM services.  M&P has one kind of savings and two kinds of checking accounts.  The savings account bears interest at the prevailing rates, compounded monthly.  Savings transactions are free as long as they are carried out at a branch and not at an ATM.  Two checking account options exist.  The Rich Club Account (RCA) bears interest at 1 percent less than the savings account rate, checks are free, and no monthly fee is applied as long as the total balance of all accounts is at least $5,000.  The Poor Slob Club (PSC) has no minimum balance. PSC accounts are charged a monthly fee of $5.00 and each check costs the customer $0.10.

6. Unit 256 2. Train Ticket Issuing System  An automated ticket issuing system sells rail tickets.  Users select their destination, and input a credit card and a personal identification number.  The rail ticket is issued and their credit card account charged with its cost.  When the user presses the start button, a menu display of potential destinations is activated along with a message to the user to select a destination.  Once a destination has been selected, users are requested to input their credit card.  Its validity is checked and the user is then requested to input a personal identifier.  When the credit transaction has been validated the ticket is issued.

7. Unit 257 3. Tic – Tac - Toe  The game is played on a 3 by 3 square board between two players.  The player who starts (‘Player X’) chooses a square of the board and puts a cross on it.  The other player (‘Player O’) chooses an empty square and puts a naught on it.  Thereafter the players continue to alternate, placing their own marks in empty squares.  The winner is the first player to complete a straight line (horizontal, vertical, or diagonal) of three of his own tokens.  If the board is filled without either player achieving this, the game is a draw.

8. Unit 258 Tic – Tac – Toe (cont’d)  To develop a framework, we need to consider the following facts and rules: 1.The game is played by two players. 2.The game is played on a square 3 by 3 board. 3.Players move alternatively. 4.To make a move is to alter the state of the bard by adding, removing and/or moving some tokens, which are things on the board. 5.Any token on the board is owned by one or other player. 6.All relevant information is available to both players. 7.Which moves are legal depends on the state of the board – which tokens are where – possibly together with other factors like the history of the play. 8.Who wins depends on the same factors.

9. Unit 259 Tic – Tac – Toe (cont’d)  (Hint: the human player interacts with a screen representation of the Naught and Crosses board, controlled by the board.  The player clicks somewhere on the board, which causes (by standard mechanisms) a message to be sent to the board, with information about where the click happened.  The board, with help from its squares, works out from the co-ordinates which square of the board has been clicked in.  The board knows that it is Player X’s turn, so the meaning of the click is that X wishes to place a token on the square.  Immediately after each move, the validity of the placement of X in a particular square is checked.  It is also checked whether or not the game is over.  If it is a valid move of Player X and the game is not over, then it is the turn of Player O.  Now the next move will be made by Player O.  The board will wait for the next click, which will represent O’s move.)

10. Unit 2510  Grady Booch, James Rumbaugh and Iver Jacobson, The Unified Modeling Language User Guide, The Addison Wesley Object Technology Series, 2000.  Stephen Gilbert and Bill McCarthy, Object Oriented Design in Java, The Waite Group Inc., 1998.  Cay Horstmann, Big java, 3 rd edition, John Wily & sons, 2002.  Stephan R. Schach, Software Engineering with Java, McGraw Hill Publications, 1998.  Ian Sommerville, Software Engineering, 6 th edition, Addison-Wesley, 2001. References