Organization and Refinement

The iterative nature of the software development model allows the greatest ease of refinement. The refinement can consist of a more loosely coupled organization to greater cohesion. It is generally a given that software (or any work for that matter) will not be perfect in the first installment or the last. Allowing for refinement, reorientation, and testing provides software engineers a means to understand and resolve some of the problems in their work.

7.8 Issues in Object-Oriented Analysis

Even with careful identification of sources of information and careful character-ization of requirements information, there will still be many problems. It is dif-ficult to provide a clean set of requirements. Software Engineers must make sure that they are addressing the problem and not adding useless enhancements to it.

Software Engineers must continuously determine if their solution to the problem is important and necessary, or if it’s an enhancement. Problems with requirement information are (Berard1993):

• Omissions: We refer to the process of focusing on the essential (or important) details of an item or situation while ignoring the inessential. Very often, the initial set of user-supplied information is incomplete. This means that during the course of analysis, the software engineer will be expected to locate and/or generate new requirements information. This new information is, of course, subject to the approval of the client.

• Contradictions: Contradictions may be the result of incomplete information, imprecise Specification methods, a misunderstanding, or lack of a consistency check on the requirements. If the user alone cannot resolve the contradictions, the software engineer will be required to propose a resolution to each problem.

• Ambiguities: Ambiguities are due to a lack of precision in specification method and incompletely defined ideas.

• Duplications: Replication of the information in the same format or replication of information in different places of same format. Software engineer must be careful in removing these.

• Inaccuracies: Most of the inaccuracies would be due assumptions. These inaccuracies must be brought to the client’s attention and resolved.

• Too much design: one of the greatest problems in requirement analysis is finding the solution to the defined problem in the same stage. A metarequire-ment is a design decision that is presented in the form of a system (product) requirement. Metarequirements describe situations and items that are not externally-discernible characteristics of the system to be delivered. True met-arequirements are not suggestions. They are items that the customer absolutely requires in the solution.

• Failure to identify properties: Sometimes, software engineers make the mis-take of assuming that any solution to the customer’s problem can only contain items that were explicitly mentioned in the problem description and/or the problem-space module. Some of the requirements properties could be implicit and hidden in other requirements.

• Irrelevant information: One straightforward way to describe a solution to a problem is to focus on what is essential, while ignoring what is inessential.

7.9 Chapter Summary and Conclusions

A requirement is a quality that a software system must have. This could be an activity that it must perform, an interface that it must contain, or an environment within which it must operate. Requirements are criteria that a system must meet if it is to work as intended, and thus if a software engineering project is to be successfully completed. In the last chapter, we discussed the process of eliciting these requirements from the client and from the end user. Those requirements first elicited, however, are far from perfect.

In this chapter we discussed the analysis phase of the software life cycle. This phase is focused on refining, improving, and finalizing the requirements specifi-cation, and a formalized understanding of the system that will be the primary resource for the rest of the development process. At the beginning of the analysis phase, requirements usually suffer from one or more of the following problems:

• omitted information

• contradictory information

• ambiguous information

• inaccurate information

• irrelevant information

The analysis phase seeks to correct these problems through the systematic evaluation, modification, and refinement of a system’s requirements gathered during the requirements elicitation phase, into a final, functional requirements specification. During analysis, systems analysts review requirements with a goal of identifying and correcting missing or erroneous information. Interviews used in the requirements elicitation phase are reviewed. When the analysts discover errors or omissions during this evaluation period, new information is gathered to fill in the

144 7 System Design

gaps by carrying out new, improved interviews. At the end of the analysis phase, a final requirements specification or requirements specification statement is formed into the specification document, which is a document that formally expresses all of the requirements that make up the system.

7.10 Exercises

1. Does object-oriented analysis preclude any kind of software implementation?

2. Describe how, in the face of changing problems, practices, people, and analysis has evolved, or should have evolved. Include a consideration of the appropri-ateness of the terms that have been used for the job.

3. Consider a file system with GUI. The following objects were identified from a use case describing how to copy a file from a floppy disk to a hard disk: FILE, ICON, Trashcan, Folder, Disk, Pointer. Start the analysis process on this.

4. Assuming the same file system before, consider a scenario consisting of selecting a File on a floppy, dragging it to a Folder and releasing the mouse.

Identify attributes and look for irrelevant objects.

5. Depict the scenario from exercise 7.4 through UML diagrams (any model described in the chapter can be used).

6. Consider a traffic light system at a four-way crossroads. Assume the simplest algorithm for cycling through the lights. Identify objects, states, attributes and draw a state chart diagram describing them.

7. You are asked to design a group scheduler. The software allows you to arrange meetings among individuals or groups, and to reserve a limited number of conference rooms. Implement the object-oriented analysis phase on this.

8. Perform OOA on the following requirements for a checkers game:

• Checkers is played by two people, one with light and one with dark pieces.

• Pieces move diagonally and opponents are captured by jumping over them.

• A piece can only move and capture forward.

• When a piece makes it to the other side of the board, it becomes a king and can move diagonally in any direction as far as it wants.

• Capturing is mandatory. A piece (or king) that is captured is removed from the board.

• The player who has no pieces left or cannot move anymore has lost the game.

• Complete the OOA phase for a Tic-Tac-Toe Computer Game using the fol-lowing description: Tic-Tac-Toe is a 2 player game played on a 3 9 3 board.

Players alternate placing a marker in one of the squares on the board. If a player gets 3 of their markers in a row, they win. If all squares are full, and neither player has 3 in a row, the game is a draw. Statistics should be kept for each player on total games won, lost and drawn. Traditional Markers are X and O.

• Design using UML and any of the OOA models for a worm game application.

In this game, a worm, controlled by the user, navigates the 2 dimensional

screen and eats pieces of ‘‘candy’’. When a piece is eaten, the worm grows by one segment. If the worm runs into the wall, or runs into itself, the worm dies and the game is over. As time increases, the speed of the worm increases. You should focus on the states of the application, but not the worm. Start from the initial state (application is not initialized) and the final state (application is destroyed). Define the states between these two. Then connect states with events and transitions (events can come to the game from the ‘‘outside’’ also).

Consider, for example, the following events:

• Start game

• Stop game

• Restart game

• Worm died

• Candy eaten

• Timer tick

Are there any other events or transitions, such as time events, signals, or self-transitions?

References

Berard EV (1993) Essays on object-oriented software engineering, vol 1. Prentice-Hall, Inc..

Booch G (1994) Object-oriented analysis and design with applications. The Benjamin/Cummings Publishing Company, Inc., New York

Burch J G (1992) Systems analysis, design, and implementation. Boyd and Fraser Publishing Company, Boston, MA

Elienes A (1995) Principles of object-oriented software development. United Kingdom University Press, Cambridge, United Kingdom

Jia X (2003) Object-oriented software development using java, 2nd edn. Pearson Education Inc., Boston

Pahl, G., & Beitz, W. Engineering Design: A Systematic Approach. ed. K. Wallace. 1996 Parnas DL (2001) On a ‘buzzword’: hierarchical structure. In Pioneers and their contributions to

software engineering, pp. 499–513. Springer, Berlin, Heidelberg

Pfleeger SL (2001) Software engineering: theory and practice, 2nd edn. Prentice Hall, Upper Saddle River, NJ

Schach S (2008) Object-oriented software engineering. McGraw-Hill Higher Education, Boston Sommerville I (2004) Software engineering, 7th edn. Peason Education, Ltd., Boston

Sommerville I (1996) Software engineering, 5th edn. Peason Education, Ltd., Boston

Turner M, Budgen D, Brereton P (2003) Turning software into a service. Computer 36(10):38–44 Weber CA, Current J, Desai A (2000) An optimization approach to determining the number of

vendors to employ. Supply Chain Manage: Int J 5(2):90–98

146 7 System Design

Object-Oriented Design