2. Chapter 7 Software Engineering

3. Objectives Understand the software life cycle. Describe the development process models. Understand the concept of modularity in software engineering. Understand the importance of quality in software engineering. Understand the role of documentation in software engineering.

4. System life cycle Software, like many other products, goes through a cycle of repeating phases.

5. System development phases The development process in the software life cycle involves 4 phases.

6. Analysis Define the user (generic or specific?) Define the needs (expectations) Define the requirements Define the methods (to meet requirements)

7. Design phase The design phase defines how the system will accomplish what was defined in the analysis phase. Modularity Tools –Structure chart –UML

8. Implementation phase Tools –Flow chart –Pseudocode Coding

9. Testing phase Black box tesing –Black box test plans are developed by looking only at the requirements statement. White box testing –White box testing is the responsibility of the programmer, who knows exactly what is going on inside the program.

10. Development process models Waterfall model: a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing and Maintenance.

11. Development process models In the incremental model, the process is developed in a series of steps. First complete a simplified version of the whole package. Gradually add more details.

12. Modularity Modularity means breaking a large project into smaller parts that can be understood and handled easily. Tools –Structure chart –Class diagram –Unified Modeling Language (UML)

13. Modularity - coupling Coupling is a measure of how tightly two modules are bound to each other. Loose coupling is more desirable, because: –Independent functions are more resuable –Less likely to cause problems –Maintenance modifications are easier

14. Modularity - coupling Data coupling: passes only the minimum required data from the calling function to the called function. Most desirable. Stamp coupling: when the parameters are composite objects such as arrays. Control coupling: passes flags to direct the control flow of a function. Global coupling: uses global variables. Should never be used. Content coupling: when one function refers directly to the data or statements in another function.

15. Modularity - cohesion Cohesion is a measure of how closely the processes in a program are related. Function cohesion: A module with function cohesion contain only one process. For example, in printing a report, the report function should call 3 lower level functions: one to get the data, one to format and print the report header, and one to format and print the data. –Only one thing –In one place

16. Modularity - cohesion Sequential cohesion: A module with sequential cohesion contains two or more related tasks that are closely tied together, usually with the output of one flowing as input to the other. Example: the calculations for a sale: –Extend item prices –Sum items –Calculate sales tax –Calculate total

17. Modularity - cohesion Communicational cohesion: It combines processes that work on the same data. Example: a function that reads an inventory file, prints the current status of the parts, and then checks to see if any parts need to be ordered. The first 3 levels of cohesion are all considered good structured programming principles. Beyond this point, ease of understanding and implementation, maintanability, and accuracy begin to drop rapidly.

18. Modularity - cohesion The 4th level, procedural cohesion, combines unrelated processes that are linked by a control flow. The 5th level, temporal cohesion, combines unrelated processes that always occur together. The last 2 levels are seldom found in programs today. Logical cohesion combines processes that are related only by the entity that controls them. Coincidental cohesion combines processes that are unrelated.

19. Quality defined Quality software is defined as: –Software that satisfies the users’ explicit and implicit requirements, is well documented, meets the operating standards of the organization, and runs efficiently on the hardware for which it was developed. If you want to attain it, you have to be able to measure it. Whenever possible, these measurements hould be quantitative. For example: # of errors per thousand lines of code, the mean time between failures for software systems.

20. Quality factors

21. Operability Accuracy can be measured by such metrics as mean time between failures, number of bugs per thousand lines of code, and number of user request for change. Efficiency is, by and large, a subjective term. In some cases, the user will specify a performance standard, such as a real-time response that must be received within 1 second 95 percent of the time. Reliability is really the sum of the other factors.

22. Operability Security: How secure a system is refers to how easy it is for unauthorized persons to get at the system’s data. Timelyness: Can mean different things, such as “Does the system deliver its output in a timely fashion?” or “Does the response time satisfy the users’ requirements?”. Usability: Highly subjective. The best measure is to watch the users and see how they are using the system.

23. Maintainability Maintainability refers to keeping a system running correctly and up to date. Changeability: how easy is it to change a system? Correctability: one measure of correctability is mean time to recovery, which is the time it takes to get a program back in operation after it fails. Flexibility: is a qualitative attribute that attempts to measure how easy it is to make these changes. Testability: how easy is it to test the system? Are complex structures employed in the code? Does the detailed design contain clear pseudo-code?

24. Transferability Transferability refers to the ability to move data and/or a system from one platform to another and to reuse code. Code reusability: is the likelihood a segment of structured code can be used again to add new functionalities with slight or no modification. Interoperability: is the ability of sending data to other systems. Portability: is the ability to move software from one hardware platform to another.

25. The quality circle

26. There are 6 steps to quality software: quality tools, techincal reviews, formal testing, change controls, standards, and measurement and reporting. Software engineers need quality tools to develop a quality product. Technical review should be conducted at every step in the development process, including requirements, design, programming, and testing.

27. The quality circle Formal testing ensures that the programs work together as a system and meet the defined requirements. To ensure quality, each change should be reviewed and approved by a change control board. A good quality environment measures all aspects of quality and regularly reports the results. At the same time, published standards provide the yardstick for many quality measurements.

28. Documentation User documentation: traditionally called a manual, user documentation shows how to use the package step by step. –A good user manual can be a very powerful marketing tool. System documentaion defines the package itself.

29. System documentation Documentation in the analysis phase. –Info collected should be carefully documented. –Analyst should define the source of info. –Requirements and methods chosen must be clearly stated with the rationale behind them.

30. System documentation Documentation in the design phase. –Tools used in the final copy must be documented. –For example, if a structural chart undergoes several changes, the final copy should be documented with complete explanations.

31. System documentation Documentation in the implementation phase. –Every tool and every program should be documented. –The program should be self-documented. –Two levels of program documentation: General documentation: each program should start with a general description of the program, then the name of the author and the date, then change history. Function documentation: whenever necessary, brief comment for blocks of code should be added.

32. System documentation Documentation in the testing phase. –Each type of test applied to the final product should be mentioned along with the result. –Even unfavorable results and the data that produced them must be documented. Documentation as an ongoing process. –If the package has problems after release,… –If the package is modified, … –Documentation stops when the package becomes obsolete.

33. Objectives Understand the software life cycle. Describe the development process models.. Understand the concept of modularity in software engineering. Understand the importance of quality in software engineering. Understand the role of documentation in software engineering.

34. Data Structures

35. Objectives Understand arrays and their usefulness. Understand records and the difference between an array and a record. Understand the concept of a linked list and the difference between an array and a linked list. Understand when to use an array and when to use a linked-list.

36. Arrays - definition An array is a fixed-sized, sequenced collection of elements of the same data type.

37. Arrays – memory layout

38. Records - definition A record is a collection of related elements, possibly of different types, having a single name. Each element in a record is called a field. A field is the smallest element of named data that has meaning. The difference between an array and a record?

39. Records - examples

40. Linked list A linked list is an ordered collection of data in which each element contains the location of the next element; that is, each element contains two parts: data and link.

41. Inserting a node

42. Deleting a node

43. Traversing a list

44. Other data structure topics Stacks (page 233) Queues (page 235) Trees (page 237) Binary trees (page 239) Graphs (page 244)

45. Objectives Understand arrays and their usefulness. Understand records and the difference between an array and a record. Understand the concept of a linked list and the difference between an array and a linked list. Understand when to use an array and when to use a linked-list.

46. Databases

47. Objectives Understand a DBMS and define its components. Understand the architecture of a DBMS and its levels. Distinguish between different database models. Understand the concept of relational database operations on a relation. Use Structured Query Language (SQL) to define simple relations.

48. Databases and DBMS A database is a collection of data that is logically, but not necessarily physically, coherent. A database management system defines, creates, and maintains a database. It also allows users controlled access to data in the database.

49. DBMS components

50. Database architecture

51. DB models - hierarchical

52. DB models – network

53. DB model - relational

54. Relation A relation, in appearance, is a two- dementional table.

55. SQL The structured query language is the standardized language we use to operate on relational databases. It is a declarative (not procedural) language, which means that the users declare what they want without having to write a step-by- step procedure.

56. Operations on relations - insert insert into COURSES values (“CIS52”, “TCP/IP Protocols”, 6)

57. Operations on relations - delete delete from COURSES where No=“CIS19”

58. Operations on relations - update update COURSES set Unit = 6 where No = “CIS51”

59. Operations on relations - select select * from COURSES where Unit = 5

60. Operations on relations - project select No, Unit from COURSES

61. Operations on relations - join select No, Course-Name, Unit, Professor from COURSES, TAUGHT-BY where COURSES.No = TAUGHT-BY.No

62. Operations on relations - union select * from CIS15-Roster union select * from CIS52-Roster

63. Operations on relations - intersection select * from CIS15-Roster intersection select * from CIS52-Roster

64. Operations on relations - difference select * from CIS15-Roster minus select * from CIS52-Roster

65. Objectives Understand a DBMS and define its components. Understand the architecture of a DBMS and its levels. Distinguish between different database models. Understand the concept of relational database operations on a relation. Use Structured Query Language (SQL) to define simple relations.