Chapter 7 Software Engineering Chapter 7 Software Engineering

Chapter 7 Software Engineering

Chapter 7: Software Engineering n n n n 7. 1 7. 2 7. 3 7. 4 7. 5 7. 6 7. 7 7. 8 The Software Engineering Discipline The Software Life Cycle Modularity Design Methodologies Tools of the Trade Testing Documentation Software Ownership and Liability 2

Software Engineering Software engineering concerns the overall process of software development and maintenance. n Large software systems cost many man-year’s efforts beyond the short-term memory capability of the human mind. n The time span may exceed one’s lifetime to work on the whole system alone. n Likewise, the increased complexity of designating many more software engineers can skyrocket over manageability. n Proper engineering disciplines are necessary to capture the complete comprehension and efficiently aggregate individual powers. n Large software systems consist of millions of lines of codes. 3

Complications of software design “Off the shelf” components available Required performance Quality metrics Scientific basis Traditional Engineering Software Engineering Often Rarely Within tolerances Perfect Mean time to failure Unclear Physics Unclear 4

Software Engineering Discipline n Significances of reliable software systems: n n �� The rising moon may be misinterpreted as a nuclear attack. �� $5 million in the Bank of New York may be lost in a day. �� Simultaneous disruption of telephone communication may occur over large regions. �� ACM & IEEE promote high standards of ethics and professional conducts. 5

Advancing our ability to build high-quality software n Researchers n n n Practitioners Theoreticians Professional organizations: ACM, IEEE, etc. n n Codes of professional ethics Standards 6

Complications in modifying software n n Changes often introduce more problems than they solve. Research addressing this problem currently focuses primarily on improving initial software development. 7

Figure 7. 1 The software life cycle 8

Figure 7. 2 The development phase of the software life cycle 9

Implementation Stage n n n Analysis identifies the needs of the users, and compiles them to requirements, further to technical specifications. Design focuses on how to accomplish these specifications and applies modular decomposition to breakdown the entire complexity. Modules may consist of procedures or objects. Create system from design n Write programs Create data files Develop databases 10

Testing Stage n Module testing: single module n n Often uses simplified simulators of other modules called stubs System testing: entire program n n Extremely difficult to perform successfully Significant open topic of research 11

Recent Trends for Software development Waterfall model Model excludes possible trial-and-errors. [flow in only one direction] n Incremental model Prototyping: Incomplete versions of the system (prototypes) built to be evaluated. n n n Evolutionary prototyping Throwaway prototyping 12

Computer Aided Software Engineering (CASE) tools n n n Project planning(cost estimation, resource arrangement, scheduling) Project management Documentation Prototyping and simulation Interface design Programming 13

Waterfall or evolutionary prototyping model? n n n Constructing a large building Learning through a scientific research Writing a term paper Obtaining a formal education in a university Obtaining an informal education through life experience 14

Modularity-- Program visualization techniques n n n Structure chart: displays relationships between components of a procedural design Class diagram: displays relationships between classes in an object-oriented design UML(Unified Modeling Language) is the standard for this purpose n Collaboration diagram: an enhanced class diagram 15

Figure 7. 3 A structure chart for a simple Internet “mail order” business 16

Figure 7. 5 A structure chart showing data coupling 17

Figure 7. 4 A class diagram for a simple Internet “mail order” business 18

Figure 7. 6 A collaboration diagram of a simple Internet “mail order” business 19

Modularity n Goal: minimize coupling and maximize cohesion n n Coupling: interactions between modules Cohesion: internal binding within a module 20

Coupling n n n Control coupling: one module passes control to another Data coupling: sharing of data between modules Implicit coupling: hidden coupling; frequently causes errors n n Global data = data accessible to all modules Side effects = action performed by a procedure that is not readily apparent to its caller 21

Cohesion n n Logical cohesion: logical similarity between actions and components Functional cohesion: components are focused around performance of a single activity n n Stronger than logical cohesion Cohesion in object oriented systems n n n Entire object will naturally be logically cohesive Each method should be functionally cohesive EX. Auto is logical cohesion, seat, steering wheel is functional cohesion 22

Figure 7. 7 Logical and functional cohesion within an object representing an order form in a simple Internet “mail order” business 23

Cohesion or coupling? n n For a student to learn, the subject must be presented in well-organized units with specific goals A student does not really understand a subject until the subject’s overall scope and relationship with other subjects has been grasped 24

Other design methodologies n Top-down design n n Generates cohesive, modular designs Bottom-up design n Generates reusable modules 25

Other design methodologies (continued) n Design patterns n Template libraries n n Component architecture n n Design patterns implemented as objects Multi-object components that can be assembled into complete programs Open-source development n Public evolutionary prototyping 26

Tools of Trade Data-based design techniques n n Dataflow diagram: displays how data moves through a system Entity-relationship diagram: displays relationships between entities in a system n Relationship types n n n One-to-one One-to-many Many-to-many 27

Figure 7. 8 A dataflow diagram of a simple Internet “mail order” business 28

Figure 7. 9 An entityrelationship diagram Entities: professor, class, and student. Represented by Rectangle Relationship: diamond with single or double pointer 29

Figure 7. 10 One-to-one, one-to-many, and many-to-many relationships between entities of types X and Y 30

Software testing strategies n n Glass-box testing--the software’s interior is visible to the tester. n Pareto principle--Identify the most problematic modules. n Basis path testing-to develop a set of test data such that each instruction in software is executed at least once. Black-box testing(from user’s viewpoints) n n n Boundary value analysis Redundancy testing--testing two independently developed systems for the same data. Beta testing--providing a preliminary version for public testing to learn real-life situations for better 31 refinement.

Documentation n User documentation--features explanation, helpful tips, etc. (non-technical) n Printed book for all customers n On-line help modules n System documentation--state the internal composition n Source code n n n Structure and naming conventions Comments Design documents--specifications and the underlying approaches. n CASE tools can help keep these up to date 32

Software ownership and Liability n Copyright n n Test = “substantial similarity” Filtration criteria: what is not copyrightable n n Features covered by standards Characteristics dictated by software purpose Components in the public domain “Look and feel” argument occasionally succeeds 33

Software ownership n Patents n n n Mathematical formulae are traditionally unpatentable Recent exceptions for some algorithms Trade secrets n Non-disclosure agreements are legally enforceable 34