Why do we need this course?

1. Why do we need this course? • Why engineer software? • Can’t we just hack at it, until we get something that works? • Many people/companies do this anyway… • Answer: can’t hack it if we care about quality • If a system is not put together in a well-organized manner, the chance for bugs is greater • Another answer: You can’t just hack together a 106 LOC system • Complex systems are impossible to build in an ad-hoc manner

2. Introduction: software quality • Software is often buggy • In critical applications, bugs can lead to drastic consequences • Therac-25 malfunctions killed or severely injured several people in 1985-87 • Ariane 5 launcher crash on 4/6/1996 • Airbus problems • Banking software failures • Many more • The main reason for bugs is enormous complexity of software • Need techniques to cope with this complexity

3. Quality Issues • Software is now an integral part of every facet of our societal infrastructure • Air traffic control • Telecommunication • Financial infrastructure • Poor quality software menaces the maintenance of that infrastructure • Software is the "Grand Enabler" holding the key to scientific and engineering challenges • Human genome project • Space exploration • Weather prediction

4. Why isn’t software quality up to snuff? • deliver prototypes • "leave it to the marketplace" • unsophisticated consumers • don't know what they want • tolerate high failure rates • "the computer is down" • misled by "coverups" in banking, finance, communications • lack of understanding of risks • Year 2000 (Y2K)

5. Software is everywhere • from Phillips: • TV can have 600Kbytes of code • VCR has 265Kbytes • Cell phone has 512Kbytes • Car radio has 64-256Kbytes

6. What is software? • Code • Various design documents • User manuals • Development plans, timelines, and budgets • Maintenance documents • The way of producing software (process)

7. Desirable qualities of software systems • Reliability • Performs the required functions correctly • The rate of failures is low • Maintainability • Understandability • Changeability • Simplicity • Reusability • The solution to a problem should be as general as possible • User friendliness • Efficiency

8. Some interesting numbers • About 25% of s/w projects fail • Failure rate increases as the size of the project increases • Costs about $100/LOC • Ranges between $10-$600 • Typical programmer produces about 30 LOCs a day • Ranges between 10-100 LOCs • 25 faults/KLOC • Ranges between 3-100 faults/KLOC

9. Software costs • Development costs • generally measured in hundreds to thousands of dollars per delivered LOC • many artifacts associated with a line of code • testing and analysis is usually 50% of this cost • Maintenance costs • 2-3 times as much as development

10. Software Costs Development costs reqts and design code 35% 15% testing 50% Full lifecycle costs code testing reqts/design maintenance

11. Models • Software code is too complex to reason about it directly • Need a higher level representation, called design • Captures only the most important relevant characteristics of the problem • Needs to capture the behavior of the problem accurately • Software code must conform to its design

12. Software Engineering • Name coined at the NATO Science Committee Conference, October 1968 • Engineering-- established, scientifically sound practices that well trained practitioners follow • Software Engineering-- the application of scientific knowledge to the the development and maintenance of software systems • Software-- ALL associated artifacts to assist with the development, operation, validation, and maintenance of programs/software systems • e.g., code, documentation, designs, requirements, user manuals, installation manuals, test cases, test results, bug reports, revision history, make files,...

13. The nature of software • Software is a complex, intricately interconnected data aggregate • Software Development is the process of creating such a complex product, while continuously assuring that it remains consistent • Software Engineering combines some of the approaches of classical engineering with some of the abstract approaches of mathematics

14. A software product is a complex web of intertwined software objects, connected by a multitude of diverse relations and constraints • some types of objects: • source code • designs • testcases • documentation • some types of relationships: • is invoked by • is derived from • is consistent with • is a version of

15. Projection 1000 638 475 142 113 Expansion 100 81 75 Factor 47 37.5 The ratio 30 of machine 15 lines of code to a 10 source line of code 3 Order of Magnitude Increase Every Twenty Years 1 1960 1965 1970 1975 1980 1985 1990 1995 2000 Machine Macro High Level Database On-line Prototyping Subsecond Object Large Scale Instructions Assembler Language Manager Time Oriented Reuse Sharing Programming Regression Small 4GL Testing Scale Reuse Trends in Software Expansion (Bernstein, 1997)

16. What is novel about software, compared to other fields of engineering? • product is unprecedentedly complex • application horizons expand too fast--with human demands/imagination • construction is human-intensive • solutions require unusual rigor • extremely malleable--can modify the product all too easily

17. How to increase Software Quality • Treat software as a PRODUCT produced in a systematic way by a PROCESS designed and implemented to achieve explicit quality objectives • Build quality in • Define software product formally • Define software process formally • Reason about the product and process formally • Incorporate validation as integral steps in the process

18. Software Lifecycle requirements reqts. analysis design specs validation coding validation testing adequacy maintenance revalidation

19. Waterfall Model • requirements-- a complete,consistent specification of what is needed • provides visibility for customers, developers, and managers • benchmark for testing and acceptance • reduces misunderstandings • requirements analysis • evaluate completeness and consistency • evaluate needs and constraints • evaluate feasibility and costs • development and maintenance costs • Probability of success

20. Waterfall Model (continued) • design specifications--a description of how the requirements are to be realized • high-level architectural design • low-level detailed design • design validation • traceability between requirements and design decisions • internal consistency

21. Waterfall Model (continued) • code--realization of the design in executable instructions • code validation • assure coding and documentation standards have been maintained • internal consistency • e.g., syntactic analysis, semantic analysis, type checking, interface consistency • consistency between design/requirements and code

22. Waterfall Model (continued) • testing--reveal problems, demonstrate behavior, assess reliability, evaluate non-functional requirements (e.g., performance, ease of use) • unit testing • integration testing • system testing • acceptance testing • regression testing • testing validation • adequacy of the testcases

23. Waterfall Model (continued) • maintenance--the process of modifying existing software while leaving its primary functionality intact • corrective maintenance-- fix problems (20%) • adaptive maintenance-- add new functionality/enhance existing features (30%) • perfective maintenance-- improve product (50%) • e.g., performance, maintainability • 3 primary steps • understand existing software • change existing software • revalidate existing software • maintenance involves all the previous phases of the lifecycle

24. Is the waterfall model an appropriate process model? • recognizes distinct activities • clearly oversimplifies the process • wait, wait, wait, surprise model • actual processes are more complex • numerous iterations among phases • not purely top down • decomposition into subsystems • many variations of the waterfall model • prototyping • re-engineering • risk reduction • ...

25. Barriers to engineering software • Industry’s short term focus • Shortage of skilled personnel • Inadequate investment in R&D • Poor technology transfer models • Insufficient standards

26. Industry’s short term focus • "bottom line orientation" • emphasis on time to market • not life cycle • return on investment • startups cannot invest in R&D until product established in marketplace • without the R&D, takes too long for next or improved product • market strategy driven by investors who want impressive short term gains

27. Industry’s short term focus • software houses • intensely competitive • often don't use own technology • keep development cost down, fix later • unsophisticated industries • lack of technical expertise • lack of administrative experience • overselling the technology

28. Barriers to engineering software • industry’s short term focus • shortage of skilled personnel • inadequate investment in R&D • PITAC (Kennedy-Joy) Report • US SW GNP is $228B but less than 1% spent on R&D • Poor technology transfer models • tend to "toss over the fence" • Lack of standards

29. What do we need? • Scientific basis • Organized discipline • R&D strategy • Trained professionals • Technology transfer strategies • Quality control

30. Certification and Licensing? • Currently, software engineering is not one of the 36 engineering professions recognized and licensed in the United States. • 48 states prohibit using the term "engineer" without a license • Texas has forced universities to stop MSSE • Tennessee prohibits the use of "software engineering" in business literature and advertising • New Jersey considered, but did not pass, a regulation that would have required licensing of all SW professionals • IEEE/CS & ACM established Commission on Software Engineering in 1993

31. High-level Goals of Software Engineering • improve productivity • reduce resourcese.g., time, cost, personnel • improve predictability • improve maintainability • improve quality

32. Basic OO terms: object and class • Object • represents anything that can be distinctly identified • has a unique identity • what does it represent? • Has a unique state • what is it doing? • Has a set of possible behaviors • what are all possible things it can be doing? • Class • represents a set of objects with similar characteristics and behavior • in other words, the type of an object

33. UML Class notation Class Name field 1 … field n method 1 … method n

34. UML Java Example: class Tree Class Tree { private float height_; private int noOfBranches_; private Classification species_; public void die() { … } public void germinate() { … } public void grow(Date untilDate) { … } public void shedLeaves() { … } }

35. Interaction among objects • An OO program is a collection of communicating objects • This communication happens via message passing • To send a message to object b, object a has to call a method of b • b.<method name>(<parameter 1>…<parameter k>);

36. Modules • A module is a part of an application • A module captures some well-defined functionality • Modules can be defined hierarchically • A module can contain a number of lower-level modules • A module consists of entities • Functions • Algorithms • Objects • Lower-level modules • A module can be a class

37. Important OO principles: cohesion and coupling • Cohesion refers to how well the entities of a class fit together • High cohesion, good • entities are highly related • Low cohesion, bad • entities are not highly related • Coupling refers to the amount of dependency among the modules • High coupling, bad • the amount of information that one module should reveal to another is excessive • Low coupling, good

38. Important OO principles: abstraction and encapsulation • Abstraction in terms of a module represents the amount of information that the users of this module need to be able to use it • The smaller this amount of information, the better • Encapsulation is the principle of not making “internal” information visible to the users • Also known as information hiding • Encapsulation improves abstraction • Internal changes can be made without affecting the way that users use this module

39. Module Interface Module Important OO principles: interface • Interface to a module is the amount of information that this module makes visible • Abstraction can be characterized as complexity of the interface • Interface represents a contract between the module and its users • the module: “Here are all the services that I can provide to you” • UML notation

40. Important OO principles: inheritance • The idea is to define a relationship where class A is more general than class B • B inherits from A • B is a subclass of A • A is a superclass of B • B is a kind of A • Example:

41. Inheritance (cont.) • Multiple levels of inheritance are possible • Subclasses inherit attributes and methods of their superclasses

42. Important OO principles: polymorphism • A related but different kinds of functionality can be implemented by several different modules • If the interfaces to all these modules are the same, they can be used in exactly the same way • In the program, a module being used can be changed dynamically, as long as the interface remains the same

43. Important OO concepts: aggregation • Aggregation is a relationship where one class is a part of another

44. Important OO concepts: association • Association is a general relationship among two classes

45. Class diagram for a game of dice

46. Modeling dynamic behaviors: state and sequence diagrams • Static behavior represents relationships among classes • Class diagrams • inheritance • aggregation • association • Dynamic behavior represents interactions among objects • State diagrams • Sequence diagrams

47. State diagrams • Represent all possible behaviors of an object • Consist of states and transitions • At any moment of time, an object is in some state • Doing something • Having certain qualities • A transition represents the object moving from one state to another • Transitions are triggered by events • May have guards and side-effects • Has a start state • May have a final state • States can be composite, called hyperstates

48. State diagram example: Game class

49. Sequence diagrams • Illustrate interaction of several objects

50. Annotations • Annotations, or comments, may be added to any part of any UML diagram • Notation: Car This class serves as a very general type of a car. You have to instantiate one of its children