Software Engineering For Students: A Programming Approach Part 44 pps

Commands are provided to: ■ cut selected text and copy it to the clip board, replacing any text already in the clip board ■ copy selected text to the clip board, replacing any text alrea

408 Appendix A ■Case studies

The user must first offer up their card to the reader The display then asks the user

to enter their PIN, via the keyboard If this is successful, the display presents a set of options

The system must be highly robust, since it is to be used by untrained bank customers

in public places

This is an example of general-purpose software that would be used by a large number

of diverse people

The word processor provides facilities for its user to enter text, amend text, save text, print text and retrieve a saved document from a file

The word processor displays a blank panel which displays text entered from the keyboard

The user can:

■ save the document in a specified file

■ retrieve a document from a specified file

■ print the document

A document consists of sentences ending in a period character A paragraph consists

of zero or several sentences ending in a special end-of-paragraph character A new page break can be inserted anywhere within a document

A section of text can be selected by clicking just before the start of some text, then dragging the cursor with the button down Selected text is shown highlighted The clip board is a temporary storage that is not visible Commands are provided to:

■ cut selected text and copy it to the clip board, replacing any text already in the clip board

■ copy selected text to the clip board, replacing any text already in the clip board

■ paste text at the cursor position from the clip board

A document can be displayed either as raw text or as formatted text suitable for printing

Cyberspace invaders is a variation of a game that was popular in the early days of com-puter games This software is appealing because it has a fun user interface It is also easy

to see a connection between the visual appearance and the software structure The spec-ification is as follows

A window displays a defender and an alien (Figure A.1) The alien moves sideways When it hits a wall, it reverses its direction The alien randomly launches a bomb that moves vertically downwards If a bomb hits the defender, the user loses and the game

A.4 The library 409

is over The defender moves left or right according to mouse movements When the mouse is clicked, the defender launches a laser that moves upwards If a laser hits the alien, the user wins and the game is over

A button is provided to start a new game

This application is a typical information system

Software is required to maintain information about books held in a library The sys-tem is intended for use by the library staff

The software must run on standard networked PCs There may be up to 20 PCs on the library network

For each book, the following information is held in the computer:

■ title

■ author

A.4 ● The library

Figure A.1 Cyberspace invaders

410 Appendix A ■Case studies

■ year

■ borrower identification (if on loan)

■ date of issue (if on loan)

The computer should be able to store information on up to 100,000 books The computer system should provide facilities to:

■ issue a book to a borrower

■ receive a book returned by a borrower

■ create information about a newly acquired book

■ display a list of the books on loan to a particular borrower

The facilities should be accessible via a GUI

The computer must respond within one second to any request

The system should provide a search facility to find out whether the library possesses

a particular book

With suitable security precautions, the system will initialize the library information

so that it contains zero books

When a book becomes overdue, the system should display appropriate information The system should provide secure access by only the library staff

The software must be delivered by such-and-such a date and cost no more than

$100,000 It must be fully documented and easy to maintain

This is an example of a safety-critical system Other similar systems include a control sys-tem for a power station and a fly-by-wire syssys-tem for an airplane

A computer system monitors the vital signs of a patient in a hospital Sensors attached to a patient continually send information to the computer:

■ heart rate

■ temperature

■ blood pressure

Some of the readings require conversion to useful units of measurement (e.g micro volts into degrees centigrade) The computer displays the information on a screen It also logs the information in a file that can be retrieved and displayed If any of the vital signs exceed safe limits, the screen flashes a warning and an alarm sounds The limits have default values, but can also be changed by the operator If a sensor fails, the screen flashes a warning and the alarm sounds

Within the field of software engineering, different people use terms differently The fol-lowing are the meanings of terms as used in this book

development approach– a particular collection of tools, methods and work styles that are used in carrying out software development

development life cycle– the complete process of software development from inception through to release and maintenance of the product

development process– specific activities that are carried out during software development

maintenance – fixing bugs, responding to changed requirements and upgrading the software for a new platform

method– the term for a procedure, subprogram or subroutine

methodology

1. the study of methods, or

2. a collection of methods, techniques and notations used for software development

portability

1. the degree to which a piece of software runs on different platforms (machine and/or operating system), or

2. the issue of whether software needs to run on different platforms

porting– moving a piece of software to a new platform

process model– idealized plan of software development in general, or an analysis of the approach adopted for a particular software development project

APPENDIX

The Unified Modeling Language (UML) is a graphical notation for describing object-oriented software It is not a method for design, but a notation that can help with designing software or help to document software once it is complete

This appendix gives a summary of those aspects of UML used in this book UML is

a large and potentially complex notation and therefore we have only used a part of the notation Thus the diagrams described and used in this book are:

■ use case diagrams

■ class diagrams

■ package diagrams

■ activity diagrams

These diagrams describe, in outline, the use cases associated with a system Figure C.1 shows an example of a use case diagram for users of a bank ATM In this example there

is a single type of user, a bank customer A customer can ask the system to carry out either of two functions – withdraw cash and check balance

APPENDIX

withdraw cash

check balance Bank Customer

Figure C.1 A use case diagram

C.2 Class diagrams 413

These describe classes and their interrelationships Classes are shown as rectangles con-taining the class name The simplest relationship is where a class uses another For example, in Figure C.2, class Game uses classes Defender, Alien, Laser and Bomb This means that Gamecreates objects from these classes and/or calls methods in objects created from these classes

A class diagram can also show the inheritance relationships between classes – the sub-classes and supersub-classes As illustrated in Figure C.3, to show that a class extends another,

a line is drawn from the subclass to the superclass, with the arrowhead pointing to the superclass Thus Spriteis the superclass of both Alienand Bomb

If a class is an abstract class, the name of the class is written in italics This can be dif-ficult to see, particularly when hand-written So the name of an abstract class can be fol-lowed by the text {abstract}to clarify the meaning

An interface is described in the same way as a class – as a box The difference is that the text <<interface>>precedes the name A class that implements an interface has

a dashed line with an arrow leading to the interface box (see Figure C.4)

A class can be described in more detail, as illustrated in Figure C.5 There are three compartments in this type of class diagram The first compartment holds the class

C.2 ● Class diagrams

Defender

Alien

Laser

Bomb Game

Figure C.2 Class diagram

Sprite

Figure C.3 Class diagram showing inheritance

414 Appendix C■ UML summary

name, the second describes variables and the third describes methods Any class (static) variables or methods are shown underlined The visibility of an element can, optionally,

be described in a prefix as in Java – public, private, protectedor default

In keeping with information hiding, the diagram is often drawn with the second compartment (the variables) omitted

A package can be diagrammed as shown in Figure C.6 It is a rectangle with a tab at the top that holds the package name Optionally, the classes within a package can be shown within the rectangle This shows a class util that consists of classes Random,

ArrayListand Stack

An activity diagram describes a sequence of activities Thus an activity diagram can be

used to show the flow of control through software An activity diagram can show:

■ conditions (corresponding to ifstatements)

■ loops (corresponding to forand whilestatements)

■ concurrent activity (corresponding to threads)

C.4 ● Activity diagrams

<<interface>>

StackInterface

Stack

Figure C.4 A class and its interface The arrow should be hollow

panel timer Game

mouseMoved mouseClicked actionPerformed

Figure C.5 Class diagram showing the detail of a class

C.4 Activity diagrams 415

An activity diagram can also be used to show a human activity, such as carrying out throwaway prototyping, Figure C.7 Actions are written in boxes with curved corners The sequence of actions is shown by the arrows A sequence starts with a special “blob” symbol A sequence ends with a different symbol, as shown

util

Stack

Random

ArrayList

Figure C.6 A package diagram

Construct prototype

Check with user

Refine prototype

Deliver the specification

Draw up an outline specification

[User requires change]

[User happy]

Figure C.7 Activity diagram showing throwaway prototyping

416 Appendix C■ UML summary

This diagram also uses the diamond-shaped branch symbol Associated with each output from the branch is a condition (termed a guard) If the condition is true, the route is taken – just as in an ifstatement

Further reading

•

Two very clear and readable books on UML are:

Martin Fowler, UML Distilled, Addison-Wesley.

Perdita Stevens, and Rob Pooley, Using UML, Addison-Wesley.

References to books and websites are given at the end of each chapter This bibliogra-phy presents some general sources Dates are not given because new editions of them are produced frequently

Here are the major books on the subject:

Ian Sommerville, Software Engineering, Addison-Wesley.

Carlo Ghezzi, Mehdi Jazayeri and Dino Mandrioli, Fundamentals of Software

Engineering, Prentice Hall.

Hans van Vliet, Software Engineering: Principles and Practice, John Wiley.

Roger S Pressman, Software Engineering, a Practitioner’s Approach, McGraw-Hill.

The Software Engineering Institute at Carnegie Mellon University, USA, is a prestigious organization They publish articles on software engineering topics and were the instigators of the capability maturity model Their website is at: http://www.sei.cmu.edu/

Here are two short and simple books on UML:

Martin Fowler, UML Distilled, Addison-Wesley.

Perdita Stevens and Rob Pooley, Using UML, Addison-Wesley.

UML

Software engineering

Bibliography