Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
APPENDIX B Glossary Within the field of software engineering, different people use terms differently. The following 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 C The Unified Modeling Language (UML) is a graphical notation for describing objectoriented 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. C.1 ● Use case diagrams UML summary 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. Figure C.1 A use case diagram Bank Customer withdraw cash check balance
- Page 383 and 384: 360 Chapter 29 ■ Software metrics
- Page 385 and 386: 362 Chapter 29 ■ Software metrics
- Page 387 and 388: 364 Chapter 29 ■ Software metrics
- Page 389 and 390: 366 Chapter 29 ■ Software metrics
- Page 391 and 392: 368 Chapter 29 ■ Software metrics
- Page 393 and 394: CHAPTER 30 This chapter: 30.1 ● I
- Page 395 and 396: 372 Chapter 30 ■ Project manageme
- Page 397 and 398: 374 Chapter 30 ■ Project manageme
- Page 399 and 400: 376 Chapter 30 ■ Project manageme
- Page 401 and 402: 378 Chapter 30 ■ Project manageme
- Page 403 and 404: 380 Chapter 30 ■ Project manageme
- Page 405 and 406: 382 Chapter 30 ■ Project manageme
- Page 408 and 409: CHAPTER 31 This chapter: 31.1 ● I
- Page 410 and 411: 31.3 Case study - assessing verific
- Page 412 and 413: 31.5 A single development method? 3
- Page 414 and 415: Further reading 391 31.2 Draw up a
- Page 416 and 417: 32.3 ● The world of programming l
- Page 418 and 419: 32.5 ● The real world of software
- Page 420 and 421: 32.6 Control versus skill 397 Final
- Page 422 and 423: Formal methods 32.7 Future methods
- Page 424 and 425: Summary 401 In the short-term futur
- Page 426: Further reading 403 An extensive tr
- Page 430 and 431: APPENDIX A Case studies are used th
- Page 432 and 433: Figure A.1 Cyberspace invaders A.4
- Page 436 and 437: C.2 ● Class diagrams C.2 Class di
- Page 438 and 439: util Figure C.6 A package diagram S
- Page 440 and 441: References to books and websites ar
- Page 442 and 443: abstraction 99, 107 acceptance test
- Page 444 and 445: fork 324 formal methods 276, 388, 3
- Page 446 and 447: quality 18, 362 quality assurance 1
APPENDIX<br />
B Glossary<br />
Within the field of software engineering, different people use terms differently. The following<br />
are the meanings of terms as used in this book.<br />
development approach – a particular collection of tools, methods and work styles that<br />
are used in carrying out software development<br />
development life cycle – the complete process of software development from inception<br />
through to release and maintenance of the product<br />
development process – specific activities that are carried out during software development<br />
maintenance – fixing bugs, responding to changed requirements and upgrading the<br />
software <strong>for</strong> a new plat<strong>for</strong>m<br />
method – the term <strong>for</strong> a procedure, subprogram or subroutine<br />
methodology<br />
1. the study of methods, or<br />
2. a collection of methods, techniques and notations used <strong>for</strong> software development<br />
portability<br />
1. the degree to which a piece of software runs on different plat<strong>for</strong>ms (machine<br />
and/or operating system), or<br />
2. the issue of whether software needs to run on different plat<strong>for</strong>ms<br />
porting – moving a piece of software to a new plat<strong>for</strong>m<br />
process model – idealized plan of software development in general, or an analysis of<br />
the approach adopted <strong>for</strong> a particular software development project
Change language