2. Ch3: Software Engineering Principles

3. 1 What is a principle?  Definition:  Goals of accounting principles:  Goals of software engineering principles?

4. 2 Why are software engineering principles needed?  Characteristics of target software  Summary:

5. 3 Outline  Principles involve software engineering process and product  Seven important principles used in all phases of software development  Cornerstone principle:

6. 4 Rigor and formality: Motivation Problem statement: Write a program that computes the square root of a number What is wrong/missing in this simple problem statement?

7. 5 Rigor and formality: Motivation More rigorous problem statement: Write a program to compute the square root of a given number. The program accepts positive and negative numbers as well as zero as input. If the input is a positive number, then the output should be both positive and negative square roots of the number. If the input is zero, then the output should be zero. If the input is a negative number, then the program should print an error message and exit. Can you find anything lacking in this problem statement?

8. 6 Rigor and formality: Motivation What is formality? SquareRoot(x) Output = + sqrt(x), if x > 0 = 0 if x = 0 = “Error” if x < 0 Input x;

9. 7 Rigor and formality  Software engineering is a creative design activity:  Why is rigor necessary?  What is formality?

10. 8 Rigor and formality (contd..)  Who should practice rigor and formality?  When should rigor and formality be practiced?  Influence of rigor and formality on other software qualities

11. 9 Examples of rigor and formality  Product:  Process:

12. 10 Separation of concerns Problem statement: Positive input: Negative input: Zero: Response time: Different concerns: Address different concerns separately:

13. 11 Separation of concerns  Divide and conquer strategy:  Master complexity by:  Identify the different aspects of problem:

14. 12 Separation of concerns (contd..)  Advantages of separation of concerns supports:

15. 13 Examples  Go through phases one after the other (as in waterfall)  Keep product requirements separate

16. 14 Modularity: Motivation Problem statement: Write a program to compute the square root of a given number. The program accepts positive and negative numbers as well as zero as input. The program accepts input from an ASCII file. If the input is a positive number, then the output should be both positive and negative square roots of the number. If the input is zero, then the output should be zero. The output should be written to a file. Should the code for input and output be embedded with the code that computes square root, or should the code be in separate modules?

17. 15 Modularity: Motivation Monolithic application File i/p Square root File o/p Modular application File i/pSquare rootFile o/p

18. 16 Modularity  Definition:  Two-phase application of separation of concerns  Methodological approaches:  Is modularity unique to software engineering?

19. 17 Modularity (contd..)  Four benefits of modularity  Key supporting concepts: Cohesion and coupling  Cohesion:  Coupling:

20. 18 Modularity (contd..)  Modularity supported in programming languages:  C++:  Ada95/Java:

21. 19 Abstraction: Motivation For a module, which uses the square root program, the only relevant information is the input it accepts and the output it provides. Thus, the user of the square root program is only concerned with its input/output behavior and may ignore the details of the implementation.

22. 20 Abstraction  Definition:  Goals of advances in design and programming  Type of abstraction to apply depends on purpose

23. 21 Abstraction (contd..)  Abstraction yields models:

24. 22 Example  Programming language semantics described through an abstract machine that ignores details of the real machines used for implementation  Abstractions in process

25. 23 Anticipation of change: Motivation Problem Statement: Consider the square root program. In addition to accepting input and writing output to a file, the program should also accept input from a terminal and provide output to a terminal. File i/pSquare rootFile o/p Terminal i/p Terminal o/p What if a combination of file and terminal I/p and o/p is desired?

26. 24 Anticipation of change: Motivation Another example: Initially, the user wants an error message if the input is negative. Later, he changes his mind, and wants the complex root as output.

27. 25 Anticipation of change  Why is this necessary?  Is anticipation of change unique to computing?  Can future products be predicted?  Is planning cycle 5 or more years?

28. 26 Generality: Motivation Square root routine is being written for use in an application where its input will never be negative. Later, a new application needs square root computation. But this, time, the output should be a complex root, if input is negative.

29. 27 Generality  Why generality?  Advantages and drawbacks of generality  Some examples of generality

30. 28 Generality (contd..)  Domain and organization specific reuse  What products will company develop in the future?  Leverage additional short-term effort with long-term gains with respect to maintenance, reuse, etc.

31. 29 Generality (contd..) Domain-Independent 20% Domain-Specific 65% Application-Specific 15% Three classes of software in a typical software application

32. 30 Incrementality: Motivation To provide a quick solution, we may first write a program that accepts positive numbers as input, and provides positive square root as output. Later, we can add the capability to accept negative numbers as input. Depending on the experience of the user in using the original program, upon receiving a negative input, he may choose to: - Print an error message - Produce complex root

33. 31 Incrementality  Accepted practice across disciplines  Incrementality in software:

34. 32 Incrementality (contd..)  Advantages of incrementality:  Difficulty in constructing solutions to complex computing problems: