1. «CSI5112» D. Amyot U. Ottawa CSI 5112 Review of Software Engineering Daniel Amyot University of Ottawa 2007

2. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering2 A Few Bugs from the Past 25 Years… [http://www.wired.com/news/technology/bugs/0,2924,69355,00.html and other sources]http://www.wired.com/news/technology/bugs/0,2924,69355,00.html 1982 — Soviet gas pipeline. Operatives working for the CIA allegedly plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The resulting event is reportedly the largest non-nuclear explosion in the planet’s history. 1985-1987 — Therac-25 medical accelerator. A Canadian radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities.Therac-25 medical accelerator 1988-1996 — Kerberos Random Number Generator. The authors of the Kerberos security system neglect to properly “seed” the program’s random number generator with a truly random seed.Kerberos Random Number Generator 1990 — AT&T Network Outage. A bug in a new release of the software that controls AT&T’s #4ESS long distance switches causes these mammoth computers to crash.AT&T Network Outage 1993 — Intel Pentium floating point divide. A silicon error causes Intel’s highly promoted Pentium chip to make mistakes when dividing floating-point numbers that occur within a specific range.Intel Pentium floating point divide 1995-1996 — The Ping of Death. A lack of sanity checks and error handling in the IP fragmentation reassembly code makes it possible to crash a wide variety of operating systems by sending a malformed “ping” packet from anywhere on the internet.The Ping of Death 1996 — Ariane 5 Flight 501. Working code for the Ariane 4 rocket is reused in the Ariane 5, but the Ariane 5’s faster engines trigger a bug in an arithmetic routine inside the rocket’s flight computer.Ariane 5 Flight 501 1995-2000 — Year 2000 Problem (Y2K). Two digits for representing a year ain’t enough Year 2000 Problem (Y2K) 2000 — National Cancer Institute, Panama City. In a series of accidents, therapy planning software created by Multidata Systems International, a U.S. firm, miscalculates the proper dosage of radiation for patients undergoing radiation therapy.National Cancer Institute, Panama City 2003 — North America blackout triggered by a local outage that went undetected due to a in General Electric Energy's XA/21 monitoring software.North America blackout

3. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering3 RISK Stories by Peter G. Neumann Illustrative Risks to the Public in the Use of Computer Systems and Related Technology —http://www.csl.sri.com/users/neumann/illustrativerisks.htmlhttp://www.csl.sri.com/users/neumann/illustrativerisks.html Digest —http://catless.ncl.ac.uk/Risks/http://catless.ncl.ac.uk/Risks/ Software Horror Stories —http://www.cs.tau.ac.il/~nachumd/verify/horror.htmlhttp://www.cs.tau.ac.il/~nachumd/verify/horror.html

4. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering4 Review The review will be done in four parts. This information is meant to refresh your memory (many of these concepts should be known by now) and to motivate several aspects of the course. 1.Software and Software Engineering 2.Modelling, and Dealing with Complexity 3.Modelling with UML 1.x 4.Essential Java Features

5. «CSI5112» D. Amyot U. Ottawa Part I: Software and Software Engineering Review, CSI 5112 (Based on Lethbridge and Laganière)

6. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering6 Objective Provide elements of answers to several important questions: What is software? What is software engineering? What does quality mean in that context? What kind of software projects exist? What about software project management and process models?

7. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering7 Why Software Engineering? To address real needs of users, in a profitable way To ensure quality To ensure security (of systems, information, people) To develop large, complex systems… and small ones To reduce development time To manage risks To select appropriate alternatives To support system evolution To consider human aspects … much more than just programming

8. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering8 The Nature of Software... Software is intangible Hard to understand development effort Software is easy to reproduce Cost is in its development —Often, in other engineering products, manufacturing is the costly stage The industry is labor-intensive Hard to automate

9. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering9 The Nature of Software... Untrained people can hack something together Quality problems are hard to notice Software is easy to modify People make changes without fully understanding it Software does not ‘wear out’ It deteriorates by having its design changed: —erroneously, or —in ways that were not anticipated, thus making it complex

10. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering10 The Nature of Software Observations Much software has poor design and is getting worse Demand for software is high and rising We are in a perpetual ‘software crisis’ —Very few projects actually deliver working software, on time We have to learn to ‘engineer’ software

11. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering11 Types of Software... Custom For a specific customer Few copies in circulation Generic Sold on open market Often called —COTS —Shrink-wrapped Embedded Built into hardware Tons of copies in circulation Hard to change Real time software Control and monitoring systems Must react immediately Safety often a concern Data processing software Used to run businesses Accuracy and security of data are key Many other aspects exist, and most software integrate many aspects at different levels.

12. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering12 What is Software Engineering?... The process of solving customers’ problems by the systematic development and evolution of large, high- quality software systems within cost, time and other constraints … Solving customers’ problems This is the goal of software engineering Sometimes the solution is to buy, not build Adding unnecessary features does not help solve the problem Software engineers must communicate effectively to identify and understand the problem

13. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering13 What is Software Engineering?… … Systematic development and evolution An engineering process involves applying well understood techniques in a organized and disciplined way Many well-accepted practices have been formally standardized —e.g. by the IEEE or ISO Most development work is evolution … Large, high quality software systems Software engineering techniques are needed because large systems cannot be completely understood by one person Teamwork and co-ordination are required Key challenge: Dividing up the work and ensuring that the parts of the system work properly together The end-product that is produced must be of sufficient quality

14. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering14 What is Software Engineering? … Cost, time and other constraints Finite resources The benefit must outweigh the cost Others are competing to do the job cheaper and faster Inaccurate estimates of cost and time have caused many project failures “Software and Cathedrals are much the same: First we build them, then we pray!!!” -Sam Redwine, Jr.

15. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering15 Software Engineering: a Profession The term Software Engineering was coined in 1968 People began to realize that the principles of engineering should be applied to software development Engineering is a licensed profession In order to protect the public Engineers design artefacts following well accepted practices which involve the application of science, mathematics and economics Ethical practice is also a key tenet of the profession Examples: PEO (Ontario), OIQ (Québec)

16. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering16 Software Engineering Code of Ethics and Professional Practice, 5.2 (ACM/IEEE-CS) Complete version: http://seeri.etsu.edu/Codes/TheSECode.htm http://seeri.etsu.edu/Codes/TheSECode.htm Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

17. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering17 Software Engineering Code of Ethics and Professional Practice, 5.2 (ACM/IEEE-CS) 1.PUBLIC - Software engineers shall act consistently with the public interest. 2.CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest. 3.PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 4.JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment. 5.MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6.PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7.COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. 8.SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

18. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering18 Typical Stakeholders in Software Engineering 1. Users Those who use the software 2. Customers Those who pay for the software 3. Software developers and maintainers 4. Development Managers 5. Salesmen/Distributors Many other types of stakeholders could be discussed. Note that many roles can be fulfilled by the same person!

19. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering19 Software Quality... Usability Users can learn it and fast and get their job done easily Efficiency It doesn’t waste resources such as CPU time and memory Reliability It does what it is required to do without failing Maintainability It can be easily changed Reusability Its parts can be used in other projects, so reprogramming is not needed … and many other -ities

20. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering20 Software Quality... [http://www.cs.cf.ac.uk/user/M.Burgess/phd/index.html]http://www.cs.cf.ac.uk/user/M.Burgess/phd/index.html An example ontology…

21. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering21 Software Quality: What is at Stake? QUALITY SOFTWARE Developer: easy to design; easy to maintain; easy to reuse its parts User: easy to learn; efficient to use; helps get work done Customer: solves problems at an acceptable cost in terms of money paid and resources used Development manager: sells more and pleases customers while costing less to develop and maintain Salesman/Distributor: simple packaging; customization; warranty and updates; benefit margins

22. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering22 Software Quality The different qualities can conflict Increasing efficiency can reduce maintainability or reusability Increasing usability can reduce efficiency Setting objectives for quality is a key engineering activity You then design to meet the objectives Avoids ‘over-engineering’ which wastes money Optimizing is also sometimes necessary E.g. obtain the highest possible reliability using a fixed budget

23. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering23 Software Engineering Projects Most projects are evolutionary or maintenance projects, involving work on legacy systems Corrective projects: fixing defects Adaptive projects: changing the system in response to changes in —Operating system —Database —Rules and regulations Enhancement projects: adding new features for users Reengineering or perfective projects: changing the system internally so it is more maintainable

24. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering24 Software Engineering Projects ‘Green field’ projects New development The minority of projects

25. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering25 Software Engineering Projects Projects that involve building on a framework or a set of existing components. The framework is an application that is missing some important details. —E.g. Specific rules of organization, business logic... Such projects: —Involve plugging together components that are: -Already developed. -Provide significant functionality. —Benefit from reusing reliable software. —Provide much of the same freedom to innovate found in green field development.

26. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering26 Activities Common to Software Projects... Requirements and specification Includes —Domain analysis and problem definition —Requirements elicitation -Obtaining input from as many sources as possible —Requirements analysis -Organizing the information —Requirements specification -Writing detailed instructions about how the software should behave —Requirements validation —Requirements management

27. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering27 Activities Common to Software Projects... Design Deciding how the requirements should be implemented, using the available technology Includes: —Systems engineering: Deciding what should be in hardware and what in software —Software architecture: Dividing the system into subsystems and deciding how the subsystems will interact —Detailed design of the internals of a subsystem —User interface design —Design of databases

28. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering28 Activities Common to Software Projects Modelling Creating representations of the domain or the software —Use case modelling —Structural modelling —Dynamic and behavioural modelling —Issue modelling Programming Quality assurance Reviews and inspections Testing, validation, verification Deployment Change and process management

29. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering29 Difficulties and Risks in Software Engineering Complexity and large numbers of details Uncertainty about technology Uncertainty about requirements Uncertainty about software engineering skills Constant change Deterioration of software design Political risks Good management skills are required!

30. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering30 (Software) Project Management Project management encompasses all the activities needed to plan and execute a project: Deciding what needs to be done Estimating costs Ensuring there are suitable people to undertake the project Defining responsibilities Scheduling Making arrangements for the work continued...

31. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering31 (Software) Project Management Directing Being a technical leader Reviewing and approving decisions made by others Building morale and supporting staff Monitoring and controlling Co-ordinating the work with managers of other projects Reporting Continually striving to improve the process

32. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering32 Software Process Models Software process models are general approaches for organizing a project into activities. Help the project manager and his or her team to decide: —What work should be done; —In what sequence to perform the work. The models should be seen as aids to thinking, not rigid prescriptions of the way to do things. Each project ends up with its own unique plan.

33. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering33 Dilbert on Processes and Methodologies

34. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering34 The Opportunistic Approach

35. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering35 The Opportunistic Approach … is what occurs when an organization does not follow good engineering practices. It does not acknowledge the importance of working out the requirements and the design before implementing a system. The design of software deteriorates faster if it is not well designed. Since there are no plans, there is nothing to aim towards. There is no explicit recognition of the need for systematic testing and other forms of quality assurance. The above problems make the cost of developing and maintaining software very high.

36. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering36 The Waterfall Model V & V Requirements Gathering and Definition V & V Specification V & V Design V & V Implementation V & V Maintenance V & V Integration and Deployment

37. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering37 The Waterfall Model The classic way of looking at S.E. that accounts for the importance of requirements, design and quality assurance. The model suggests that software engineers should work in a series of stages. Before completing each stage, they should perform quality assurance (verification and validation). The waterfall model also recognizes, to a limited extent, that you sometimes have to step back to earlier stages.

38. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering38 Limitations of the Waterfall Model The model implies that you should attempt to complete a given stage before moving on to the next stage —Does not account for the fact that requirements constantly change. —It also means that customers can not use anything until the entire system is complete. The model makes no allowances for prototyping. It implies that you can get the requirements right by simply writing them down and reviewing them. The model implies that once the product is finished, everything else is maintenance.

39. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering39 The Phased-Release Model V & V Requirements Gathering and Definition V & V Specification V & V Design V & V Implementation V & V Planning Phase 1 V & V Design V & V Implementation Phase 2 etc... V & V Integration and Deployment V & V Integration and Deployment

40. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering40 The Phased-Release Model It introduces the notion of incremental development. After requirements gathering and planning, the project should be broken into separate subprojects, or phases. Each phase can be released to customers when ready. Parts of the system will be available earlier than when using a strict waterfall approach. However, it continues to suggest that all requirements be finalized at the start of development.

41. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering41 The Spiral Model Requirements Specification Design Implementation Prototype Release 1 Release 2 Review Analysis of risk Integration and deployment

42. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering42 The Spiral Model It explicitly embraces prototyping and an iterative approach to software development. Start by developing a small prototype. Followed by a mini-waterfall process, primarily to gather requirements. Then, the first prototype is reviewed. In subsequent loops, the project team performs further requirements, design, implementation and review. The first thing to do before embarking on each new loop is risk analysis. Maintenance is simply a type of on-going development.

43. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering43 The Evolutionary Model Time Development Activity

44. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering44 The Evolutionary Model It shows software development as a series of hills, each representing a separate loop of the spiral. Shows that loops, or releases, tend to overlap each other. Makes it clear that development work tends to reach a peak, at around the time of the deadline for completion. Shows that each prototype or release can take — different amounts of time to deliver; — differing amounts of effort.

45. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering45 The Concurrent Engineering Model

46. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering46 The Concurrent Engineering Model It explicitly accounts for the divide and conquer principle. Each team works in parallel on its own component, typically following a spiral or evolutionary approach. There has to be some initial planning, and periodic integration.

47. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering47 Choosing a Process Model From the waterfall model: —Incorporate the notion of stages. From the phased-release model: —Incorporate the notion of doing some initial high-level analysis, and then dividing the project into releases. From the spiral model: —Incorporate prototyping and risk analysis. From the evolutionary model: —Incorporate the notion of varying amounts of time and work, with overlapping releases. From the concurrent engineering: —Incorporate the notion of breaking the system down into components and developing them in parallel.

48. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering48 Reengineering Periodically project managers should set aside some time to re-engineer part or all of the system The extent of this work can vary considerably: —Cleaning up the code to make it more readable. —Completely replacing a layer. —Re-factoring part of the design. In general, the objective of a re-engineering activity is to increase maintainability.

49. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering49 Extreme Programming Extreme Programming (XP) was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may not have to develop large requirement documents. Instead you write a series of user stories. Project planning is based on user stories. There must be a series of small and frequent/regular releases; In many software environments dynamically changing requirements is the only constant. XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well. Extreme Listening, Testing, Coding, Designing. http://www.extremeprogramming.org

50. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering50 Dilbert on Extreme Programming…

51. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering51 Dilbert on Extreme Programming…

52. «CSI5112» D. Amyot U. Ottawa Part II: Modelling, and Dealing with Complexity Review, CSI 5112 (extract from Bernd Bruegge & Allen H. Dutoit, Object-Oriented Software Engineering: Using UML, Patterns, and Java)

53. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering53 A Game: Get-15 Start with the nine numbers 1, 2, 3, 4, 5, 6, 7, 8 and 9. You and your opponent take alternate turns, each taking a number. Each number can be taken only once: if your opponent has selected a number, you can no longer take it. The first person to have any three numbers that sums up to 15 wins the game! Example: You: Opponent: 1583 6927 Opponent Wins!

54. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering54 Characteristics of Get-15 Hard to play… The game is especially hard, if you are not allowed to write anything. Why? All the numbers need to be scanned to see if you have won/lost It is hard to see what the opponent will take if you take a certain number The choice of the number depends on all the previous numbers Not easy to devise a simple strategy

55. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering55 Another Game: Tic-Tac-Toe Source: http://boulter.com/ttt/index.cgi

56. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering56 A Draw Sitation

57. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering57 Strategy for Determining a Winning Move

58. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering58 Winning Situations for Tic-Tac-Toe Winning Patterns

59. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering59 Tic-Tac-Toe is “Easy” Why? Reduction of complexity through patterns and symmetries Patterns Knowing the following three patterns, the player can anticipate the opponents move: Symmetries The player needs to remember only these three patterns to deal with 12 different game situations The player needs to memorize only 3 opening moves and their responses

60. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering60 But Get-15 & Tic-Tac-Toe are Identical Problems! Any three numbers that solve the 15 problem also solve tic- tac-toe. Any tic-tac-toe solution is also a solution to the 15 problem To see the relationship between the two games, we simply arrange the 9 digits into the following pattern: 816 357 492

61. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering61 Example 816 357 1583 6 927 You: Opponent: 492

62. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering62 Models are Good, but… What is This?

63. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering63 Dealing with Complexity using Modelling Three important concepts: 1.Abstraction 2.Decomposition 3.Hierarchy

64. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering64 1. Abstraction Inherent human limitation to deal with complexity The 7 +/- 2 phenomena (phone numbers…) Chunking Group collection of objects Ignore unessential details  Models

65. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering65 Models are Used to Provide Abstractions System Model: Object Model: What is the structure of the system? What are the objects and how are they related? Functional model: What are the functions of the system? How is data flowing through the system? Dynamic model: How does the system react to external events? What is the event flow in the system ? Task Model: PERT Chart: What are the dependencies between the tasks? Schedule: How can this be done within the time limit? Org Chart: What are the roles in the project or organization? Issues Model: What are the open and closed issues? What are the goals and objectives? What constraints were posed by the client? What resolutions were made?

66. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering66 Different but Related Model Types Task Models PERT Chart Gantt Chart Org Chart Issue Models Constraints Issues Proposals Arguments Pro Con System Models Object Model Functional Model Dynamic Model class... Code Forward Engineering Reverse Engineering

67. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering67 Model-Based Software Engineering: Code is a Derivation of Object Model Problem Statement:A stock exchange lists many companies. Each company is identified by a ticker symbol Analysis phase results in object model (UML Class Diagram): StockExchange Company tickerSymbol Lists * * Implementation phase results in code public class StockExchange { private Vector companies = new Vector(); } public class Company { public int tickerSymbol; private Vector stockExchanges = new Vector(); } A good software engineer writes as little code as possible

68. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering68 Example of an Issue: Galileo vs the Church What is the center of the Universe? Church: The earth is the center of the universe. Why? Aristotle says so. Galileo: The sun is the center of the universe. Why? Copernicus says so. Also, the Jupiter’s moons rotate round Jupiter, not around Earth.

69. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering69 Issue-Modelling Issue: What is the Center of the Universe? Proposal1: The earth! Proposal2: The sun ! Pro: Copernicus says so. Pro: Aristotle says so. Pro: Change will disturb the people. Con: Jupiter’s moons rotate around Jupiter, not around Earth. Resolution (1615): The church decides proposal 1 is right Resolution (1998): The church declares proposal 1 was wrong

70. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering70 2. Decomposition A technique used to master complexity “divide and conquer” Functional decomposition The system is decomposed into modules Each module is a major processing step (function) in the application domain Modules can be decomposed into smaller modules Object-oriented decomposition The system is decomposed into classes (“objects”) Each class is a major abstraction in the application domain Classes can be decomposed into smaller classes Which decomposition is the right one?

71. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering71 Functional Decomposition Top Level functions Level 1 functions Level 2 functions Machine Instructions System Function Load R10 Add R1, R10 Read Input Transform Produce Output Transform Produce Output Read Input

72. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering72 Functional Decomposition Functionality is spread all over the system Maintainers must often understand the whole system to make a single change to the system Consequence: Code is hard to understand Code is complex and difficult to maintain User interface is often awkward and non-intuitive OO decomposition provides some help, but still has problems

73. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering73 What is this Thing?

74. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering74 Modelling a Briefcase BriefCase Capacity: Integer Weight: Integer Open() Close() Carry()

75. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering75 A New Use for a Briefcase BriefCase Capacity: Integer Weight: Integer Open() Close() Carry() SitOnIt()

76. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering76 Questions Why did we model the thing as “Briefcase”? Why did we not model it as a “Chair”? What do we do if the SitOnIt() operation is the most frequently used operation? What if decompositions other than functional and OO were also needed?

77. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering77 A Decomposition Problem Not all requirements can be assigned to just one component (  crosscutting concerns) Requirement1 (R1) Requirement2 (R2) Requirement3 (R3) RequirementN (RN) … Scattering: design elements to support R1 in many components Tangling: single component has elements for many requirements ComponentA R1 elements ComponentF R1 elements R2 elements R3 elements RN elements ComponentE ComponentD R1 elements ComponentB R1 elements ComponentC R1 elements [Slide from G. Mussbacher]

78. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering78 Aspect Triggered behavior (code) Predicate F.R1 One Potential Solution: Aspects ClassA R1 elements ClassC R1 elements ClassG R1 elements ClassF R1 elements R2 elements R3 elements RN elements advicepointcut Terminology based on AspectJ: www.eclipse.org/aspectj intertype declaration ClassB R1 elements (identifies joinpoints where advice is executed) R1 elements

79. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering79 3. Hierarchy We got abstractions and decomposition This leads us to chunks (classes, objects, aspects) which we view with an object model Another way to deal with complexity is to provide simple relationships between the chunks One of the most important relationships is hierarchy 2 important hierarchies "Part-of" hierarchy "Is-kind-of" hierarchy

80. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering80 Part-of Hierarchy Computer I/O Devices CPU Memory Cache ALU Program Counter

81. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering81 Is-Kind-of Hierarchy (Taxonomy) Cell Muscle Cell Blood Cell Nerve Cell Striate Smooth RedWhite Cortical Pyramidal

82. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering82 So Where Are We Right Now? Three ways to deal with complexity: Abstraction Decomposition Hierarchy Object-oriented decomposition is a good methodology Unfortunately, depending on the purpose of the system, different objects can be found Other limitations How can we do it right? Many different possibilities Suggested approach: Start with a description of the functionality (Use Case model), then proceed to the object model This leads us to interesting software lifecycle activities

83. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering83 Software Lifecycle Activities… Subsystems Structured By class... Source Code Implemented By Solution Domain Objects Realized By System Design Object Design Implemen- tation Testing Application Domain Objects Expressed in Terms Of Test Cases ? Verified By class.... ? Requirements Elicitation Use Case Model Analysis and Their Models

84. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering84 Summary Software engineering is a problem solving activity Developing quality software for a complex problem within limited time and resources while things are changing There are many ways to deal with complexity Modelling, decomposition, abstraction, hierarchy Issue models: Show the negotiation aspects —CSI 5112 emphasizes requirements engineering System models: Show the technical aspects —CSI 5112 emphasizes precise modeling with UML Task models: Show the project management aspects —CSI 5112 emphasizes project and change management Use Patterns: Reduce complexity even further

85. «CSI5112» D. Amyot U. Ottawa Part III: Modelling with UML 1.x Review, CSI 5112 (extracts from Bruegge & Dutoit, Lethbridge & Laganière, and from the Borland UML tutorial)

86. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering86 Good UML Tutorials http://bdn.borland.com/article/0,1410,31863,00.html Source of most of the figures used here UML Distilled, Third Edition Martin Fowler, ISBN 0-321-19368-7 Addison-Wesley, 2004, 208 pages UML specification http://www.omg.org/technology/documents/formal/uml.htm

87. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering87 Systems, Models, and Views A model is an abstraction describing a subset of a system (filtering out unimportant details) A view depicts selected aspects of a model A notation is a set of graphical and/or textual rules for depicting views Views and models of a single system may overlap each other. Examples: —System: Aircraft —Models: Flight simulator, scale model —Views: All blueprints, electrical wiring, fuel system

88. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering88 View 1 Model 2 View 2 View 3 Model 1 Systems, Models and Views Aircraft Flight Simulator Scale Model Blueprints Electrical Wiring System

89. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering89 Models, Views and Systems (UML) SystemModelView * * Depicted by Described by

90. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering90 Booch methodOMT (Rumbaugh) Unified Method 0.8 OOPSLA 1995 OOSE (Jacobson) Other methods UML 0.9 Web - June 1996 UML 1.1 1st submission à OMG, Jan 1997 Approval OMG, Nov 1997 UML 1.0 UML partners UML 1.3 Revision Task Force, June 1999 Revision Task Force, May 2001 UML 1.4 UML Evolution UML 2.0 Revision Task Force, Nov 2003 UML 1.5 Revision Task Force, March 2003

91. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering91 Meyer Before and after conditions Harel Statecharts Gamma, et al Frameworks and patterns HP Fusion Operation descriptions and message numbering Embley Singleton classes and high-level view Wirfs-Brock Responsibilities Odell Classification Shlaer - Mellor Object lifecycles Rumbaugh OMT Booch Booch method Jacobson OOSE Contributions to UML 1.X

92. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering92 Models and Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Deployment Diagrams State Diagrams State Diagrams Object Diagrams State Diagrams State Diagrams Class Diagrams Use Case Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Collaboration Diagrams Scenario Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams Use Case Diagrams Sequence Diagrams Activity Diagrams Models

93. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering93 RUP (Rational Unified Process) Models Use Case Diagrams Collaboration Diagrams Component Diagrams Deployment Diagrams Object Diagrams Statechart Diagrams Sequence Diagrams Class Diagrams Activity Diagrams Use Case Model Design Model Depl. Model Impl. Model Analysis Model Test Model A model may include many diagrams (views) using many notations. A notation may be used in several models.

94. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering94 Use Case Diagrams Use case diagrams represent the functionality of the system from the user’s point of view actor use case is-a relations generalization association [From L&L]

95. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering95 Content of a Use Case Bubble Use cases are often described textually or with sequence diagrams. For instance:

96. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering96 Class Diagrams Class diagrams describe the static structure of the system: Objects, Attributes, Associations

97. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering97 Object Diagrams Snapshots of run-time objects and their links

98. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering98 Object Diagrams and Class Diagrams RecordingCategory * subcategory description Recording * hasCategory title artist rockbluesclassicaljazzmusic video videoaudio subcategory :RecordingCategory 9th Symphony :Recording Let it be :Recording The Beatles Beethoven Objects are instances of classes (with real values), and links are instances of associations. No inheritance, no multiplicities.

99. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering99 Activity Diagrams Describe the dynamic behavior of a system as a flow (sequence, alternative, parallel) of activities (workflow).

100. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering100 Sequence Diagrams Describe the dynamic behavior as interactions between actors and the system and between objects of the system

101. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering101 Collaboration Diagrams 2-D view of sequence diagrams, with numbered messages

102. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering102 Describe the dynamic behavior of an individual object (with states and transitions) Statechart Diagrams

103. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering103 Component and Deployment Diagrams A component is a code module. Component diagrams are physical analogs of class diagram. Deployment diagrams describe the relationships among software and hardware components (a configuration)

104. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering104 Package Diagrams Show a structure of packages, which are collections of logically related UML elements used to simplify, manage, and reuse complex models.

105. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering105 Also in UML 1.x Object Constraint Language (OCL) Will be covered later in this course Semantic Metamodel Some aspects will be viewed in this course Profiles Some aspects will be viewed in this course Action Semantics (UML 1.5 only) Will not be used in this course

106. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering106 Dilbert on UML…

107. «CSI5112» D. Amyot U. Ottawa Part IV: Essential Java Features Review, CSI 5112 (extract from Lethbridge & Laganière, 2001, and Daniel Amyot (CSI 1500), 2004. See also http://www.site.uottawa.ca/school/research/lloseng/ BasicsOfJava.pdf) http://www.site.uottawa.ca/school/research/lloseng/ BasicsOfJava.pdf

108. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering108 Concepts that Define Object Orientation (OO) Necessary for a system or language to be OO Identity —Each object is distinct from each other object, and can be referred to —Two objects are distinct even if they have the same data Classes —The code is organized using classes, each of which describes a set of objects Inheritance —The mechanism where features in a hierarchy inherit from superclasses to subclasses Polymorphism —The mechanism by which several methods can have the same name and implement the same abstract operation

109. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering109 Other Key OO Concepts Encapsulation —Details can be hidden in classes —This gives rise to information hiding: -Programmers do not need to know all the details of a class Abstraction —Object  something in the world —Class  objects —Superclass  subclasses —Operation  methods —Attributes and associations  instance variables Modularity —Code can be constructed entirely of classes

110. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering110 The Basics of Java History The first object oriented programming language was Simula-67 —Designed to allow programmers to write simulation programs In the early 1980’s, Smalltalk was developed at Xerox PARC —New syntax, large open-source library of reusable code, bytecode, platform independence, garbage collection. late 1980’s, C++ was developed by B. Stroustrup, —Recognized the advantages of OO but also recognized that there were tremendous numbers of C programmers In 1991, engineers at Sun Microsystems started a project to design a language that could be used in consumer ‘smart devices’: Oak —When the Internet gained popularity, Sun saw an opportunity to exploit the technology. —The new language, renamed Java, was formally presented in 1995 at the SunWorld ’95 conference.

111. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering111 Tools and APIs Java2 API 1.4.2: http://java.sun.com/j2se/1.4.2/docs/api/index.htmlhttp://java.sun.com/j2se/1.4.2/docs/api/index.html 5.0: http://java.sun.com/j2se/1.5.0/docs/api/index.htmlhttp://java.sun.com/j2se/1.5.0/docs/api/index.html 6: http://java.sun.com/javase/6/docs/api/http://java.sun.com/javase/6/docs/api/ JVM Java Virtual Machine (platform-dependent) javac Java compiler (produces platform-independent bytecode) java Java interpreter (runs bytecode on a JVM) javadoc Produces HTML documentation from Java code drJavadrJava, Eclipse…Eclipse Integrated Development Environments (IDEs) for Java

112. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering112 Primitive Data Types

113. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering113 Some Basics Constructs… Assignment and sequence of instructions int var1; // defines a variable, initially at 0 int var2 = 3; // defines & initializes another one var1 = var2 + 1; // assigns 4 to var1 Comments Java instruction; // Comment, to end of line Comments can also be between /* and */ (on many lines) Displaying information System.out.println(var1); // with carriage return System.out.print("Sum: " + (var1 + var2)); // No CR. First + is concatenation, second is sum!

114. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering114 Arrays Declaration of an Array variable (of some type) double [] myArray; // Initially worth null Creating an array (reserving memory for N elements) myArray = new double[5]; // Valid indices: 0 to 4 Size of an array int theSize = myArray.length; // theSize = 5 Initializing an array during creation int[] array1 = new int [] { 3, 5, 4 }; Arrays are reference types (not primitive types) int[] array2 = array1; array2[0] = 6; // Also changes array1[0] to 6! Multidimensional arrays (not limited to 2) int [][] M; M = new int[][] { {1, 2, 3}, {4, 5, 6} };

115. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering115 A Very Useful Type: String Esay to manipulate String hi = "Hello"; String message = hi + " world!"; System.out.println( message ); // displays Hello world! Comparisons String str1 = "abcde" ; String str2 = "abcfg" ; String str3 = "ab" ; boolean c1 = str1.equals(str2); // false int c2 = str1.compareTo(str3); // > 0 // Many other operations in the String class

116. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering116 Operators and Their Precedence () (expression) [] (array index). (object member) + – (unary plus/minus) ! (negation) * / % (modulus) + - (binary addition/substraction) >= <= == != && (logical AND) || (logical OR) = (assignment)

117. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering117 Control Structures Conditions if (x < 5) // Boolean expression { doThis(); // list of instructions } else { doThat(); // list of instructions } Loops while (Test) // some Boolean expression { body(); // list of instructions } for (int i = 0; i < 9; i++) { m = m + i; // body, repeated 9 times }

118. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering118 Classes with a Main Method public class HelloWorldApp { // main is a special, runnable method public static void main(String[] args) { System.out.println("Hello World!"); }

119. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering119 Classes and Objects Class definition class Time { public int hours; public int minutes; } Class instances (objects) Time myTime; // definition, initially set to null myTime = new Time( ); // new object created myTime.hours = 17; myTime.minutes = 45;

120. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering120 Attributes and Methods Classes can contain attributes and/or methods class Time { private int hours; private int minutes; public void setTime(int h, int minutes) // Setter method { this.hours = h; // this is optional here this.minutes = minutes; // this is not optional here } public int getHours() // Getter method { return hours; } public int getMinutes( ) // Another getter method { return this.minutes; // this is optional here }

121. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering121 Visibility and Encapsulation public : A public method can be invoked by any other method in any other object or class. protected : A protected method can be invoked by any method in the class in which it is defined or any subclasses of that class. private : A private method can only be invoked by other method in the class in which it is defined, but not in the subclasses. (default, no keyword) : The method is effectively public to all other classes within the same package, but private to classes external to the package. This is sometimes called package visibility or friendly visibility. These visibility modifiers can help reducing coupling in complex Java programs. They can also be applied to variables (fields) in a class.

122. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering122 Class and Instance Variables/Methods The static keyword is used to specify class variables or methods (common to all instances of the classes). A non-static (instance) variable will have a content possibly different for all objects of that class. Static methods are limited to accessing static variables. public static boolean isEqual( Time t1, Time t2 ) { return (t1.getHours() == t2.getHours()) && (t1.getMinutes() == t2.getMinutes()); } // Polymorphism allows for both methods in the same class! public boolean isEqual( Time t2 ) { return (this.hours == t2.getHours()) && (this.minutes == t2.getMinutes()); } public static final MAXMINUTES=60; // final means constant

123. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering123 Constructors Invoked when we create an object. Usually initialize class fields. // Constructor by default. Implicit in Java if no // constructor specified, overridden otherwise. // Constructors have the class name and return nothing. public Time() { ; // do nothing to the fields! } // Another constructor, with parameters. public Time(int h, int m) { this.minutes = m % 60; // Handles the case where m>59 this.hours = h + m/60; } // Java uses garbage collection, hence destructors are not supported. Creation of objects with new Time t1 = new Time(); // Uses first constructor, hours = minutes = 0 Time t2 = new Time(3, 45); // Uses second constructor, 3:45

124. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering124 Inheritance import java.applet.*; import java.awt.*; /** * The HelloWorld class implements an applet that * simply displays "Hello World!". */ public class HelloWorld extends Applet // Single inheritance only in Java { public void paint(Graphics g) { // Display "Hello World!" g.drawString("Hello world!", 50, 25); }

125. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering125 Exceptions Anything that can go wrong should result in the raising of an Exception Exception is a class with many subclasses for specific things that can go wrong Use a try - catch block to trap an exception try { // some code } catch (ArithmeticException e) { // code to handle division by zero }

126. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering126 Interfaces Like abstract classes, but cannot have executable statements Define a set of operations that make sense in several classes Abstract Data Types Can be used to “fake” multiple inheritance A class can implement any number of interfaces It must have concrete methods for the operations Important interfaces in Java’s library include Runnable, Collection, Iterator, Comparable, Cloneable

127. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering127 Packages and Importing A package combines related classes into subsystems All the classes in a particular directory Classes in different packages can have the same name Although not recommended Importing a package is done as follows: import java.applet.*; import finance.banking.accounts.*; // A good practice is to avoid the * and // enumerate the exact classes imported.

128. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering128 Threads and Concurrency Thread Sequence of executing statements that can be running concurrently with other threads To create a thread in Java 1.Create a class implementing the Runnable interface or extending Thread 2.Implement the run method as a loop that does something for a period of time 3.Create an instance of this class 4.Invoke the start operation, which in turn calls run

129. «CSI5112» D. Amyot U. Ottawa Review of Software Engineering129 Dilbert on Programming…