CMPT 275 Software Engineering

1. CMPT 275Software Engineering Introduction

2. Important Topics • Why is Software Engineering Important? • What is Software Engineering? • a brief historical review • Software Engineering Methods/Concepts/Activities • Various Software Development Paradigms • What makes a “Good” Software System?

3. Why is Software Important? • Software controls much of the technology we have come to rely on • For many applications it is essential that the software be correct and stable • What if you transferred money between accounts electronically and it disappeared without a trace? • What if the medical scanning equipment malfunctioned and gave you a critical dose of radiation? • Other examples?

4. Why Software Engineering? • In software critical applications software must be engineered and verified to assure its correctness and stability • As technology increases in complexity, it becomes necessary for many people to work on any application • When many people work on one project techniques to work efficiently as a group are essential!

5. Why Else? • Many software development projects fail to produce a final product, or produce a product that is not viable. • Software development: Need to identify the sources of the problems and implement procedures and design approaches that avoid the pitfalls.

6. Therac 25: 1 example of failure • A therapeutic linear accelerator • Developed by a single developer, incrementally (by addition/change) over many generations of the product • A rare sequence of input parameters caused deaths of several patients. • Each death was treated as an isolated incident and software ‘patched’ to fix the perceived problem that caused that isolated incident

7. Therac 25: Actual problem • In truth there was 1 problem, a race condition: • Magnets to tailor dose for patient needed to be moved as each treatment was set up • It was possible to start the treatment before the magnets were in place, causing an incorrect dose of radiation to be administered. • Error messages provided by the system were incorrect in some instances because this possible condition had not been considered to be ‘likely’ to occur

8. Examples of past problems • Links given on the course readings and notes page summarize some failed software development projects • Air traffic control case study: $2.3 billion spent without any usable deliverable • This case is NOT an unusual exception, failure has been common • Can you give me other examples from your pre lecture reading? • Common Link: Software systems are complex, complexity often leads to problems

9. Controlling complexity • When a large system is being developed it is essential to design (engineer) the software • The project must be divided into manageable units • Clear interfaces between the units must be defined and adhered to

10. Clear Interfaces • Each of the unit will be assigned to a programmer or group of programmers. This group may have no knowledge of what other units are and how their unit fits into the larger project. • To assure that all units will integrate smoothly into the final large system design is essential and clear interfaces between units must be defined early in the project • A small change by one group to ‘improve’ the interface will cause disaster at integration time if it is not communicated to and agreed upon by all groups involved

11. Other Sources of Complexity • The problem being solved • the application domain in which the problem lies • Communication failure between programmers and application domain specialists • The software itself • Problems can be made more difficult by choosing the wrong algorithm or implementation tools.

12. Sources of Complexity • The size of the software development project • Difficult to keep track of all the details of large software project without formal processes • Difficult to coordinate team effort as size of development team grows. Need effective methods to allocate components of the project and maintain communication between programmers/groups.

13. CommunicationBreakdown: • In the course of the development of a large project many groups of developers will be involved • Each of these groups will add/lose members during the project • Need documentation in addition to interpersonal communication to pass on knowledge about the project • Need good communication to assure those interfaces and designs are understood in the same ways by each group involved

14. CommunicationBreakdown: • Software developers and end users have • different background knowledge • different vocabulary • Application domain vocabulary (medical, scientific, business …) • Different from software developers technical vocabulary • In some areas a “Business Analyst” role bridges this gap • In otherareas a person who speaks both ‘languages’ is needed

15. Examples: Application Domain • Advertisement for software developer “Located in Cambridge, UK, this client develops software products for the printing industry. Their products are used in areas such as the graphic arts, web publishing and corporate markets. They are seeking a developer to assist in the development of solutions for customers. You will have : a degree (or equivalent) in computer science or similar, 5+ years of C / C++ development on Windows / NT / MAC. Knowledge of pre-press or electronic publishing systems is ESSENTIAL.”

16. CommunicationBreakdown: 2 • Software developers in different areas have different backgrounds and knowledge • Still a vocabulary problem (Technical background outside software development differs) • One group of developers on one part of the project, may be unaware of ‘obvious’ constraints imposed in another area • Technical background may cause different groups of developers to interpret a requirement differently

17. Design for easy Maintenance ! • A software system that is difficult to maintain may be unsuccessful when put into production • If fixes, upgrades and modifications are difficult to make the lifetime of the application will be short • Maintenance is part of life cycle of software system • Systems should be designed for easy maintenance • Organizations’ needs change as they grow and adapt to the marketplace • Software that is poorly structured or documented will require large and costly maintenance efforts

18. Bottom line is… • Software development initiatives may fail because of thousands of reasons • Software engineering emerged as a way to alleviate these failures • e.g: reduce maintenance efforts by developing well-structured and modularized software system

19. What is Software Engineering? “Software Engineering is intended to mean the best-practice processes used to create and/or maintain software, whether for groups or individuals, in attempt to rid ourselves of the usual haphazard methods that have plagued the software industry.” From http://www.practicalprocess.com/seyp/definition.html

20. Objective of Software Engineering • To organize and control software development process and produce a well-structured, accurate and useful software solution.

21. Software Engineering is • Modeling • to manage details (complexity) • Problem solving • using models to search for information and alternatives that can be completed with the available resources • Knowledge acquisition • Remembering rational • Rational preserves the context of the system, why decisions were made and options chosen earlier in development of the system

22. Modeling • A model is an abstract representation of a system used to answer questions about that system • The systems we make models of in software engineering are artificial systems • Models can be made of (man made) artificial systems. These models can be used to determined if the system can be built

23. Modeling • Models can also be used to: • Assess the practicality and usefulness of the system • Estimate the cost and development time of the system • Develop a implementable approach to building the system with the desired functionality • And more …

24. Problem Solving • The Software development method is based on the steps used to solve any other problem • Formulate the problem • Analyze the problem • Specify the problem clearly and in detail, capture the rational of the problem • Search for ways to solve the problem • Decide on the ‘best’, most appropriate solution • Specify the solution clearly and in detail, capture the rational of the solution • Implement the solution • Test/Verify the implementation • Deliver and maintain the resulting system

25. No Software Engineering? • Why do some groups or companies, not use software engineering in their software development • Attitude of some managers (not trained in software engineering) towards software development • Design and documentation is a waste of time • Production of lines of source code (# of LOC) or implementation of numbers of features as the sole measures of progress of project • End users should only be involved at the beginning and end of the software development process. OR • End users can add requests for additional functionality at any time • Poor project estimation, unreasonable deadlines • Causes programmers to cut corners, omit documentation, ‘patch’ or ‘hack’ rather than design and implement • Leads to maintenance nightmares

26. Software Development Paradigms • Paradigm:The generally accepted view or perspective held by a group or subject discipline. • Software Development Paradigm: Set of techniques used to guide the software development process.

27. Evolution of software paradigms • Early computers could only solve ‘small’ problems. Solutions were ‘simple’ and were implemented with ‘basic’ tools • As computers evolved and became more powerful, larger and more complex problems became solvable • As problems became more complex, software development paradigms evolved to manage the complexity

28. paradigm evolution • Let’s take a quick look at the evolution of software development paradigms • Early programs were written in assembler and had minimal or no formal methods for design • Higher level languages were invented to simplify programming, still no formal methods for design • Higher level languages continued to evolve

29. Early Software Engineering - 1 • Structured Programming (late 60’s, early 70’s) • Avoid goto’s • For more about goto's see • www.acm.org/classics/oct95/ • www.cs.pdx.edu/~apt/cs302_1999/lecture5/lecture5.html • www.azillionmonkeys.com/qed/goto.html • In Structured Programming, goto's are replaced by function calls and loops, hence structure and control flow is simplified • This gives a cleaner and easier to understand implementation and improves the ease of maintenance

30. 30 continue 40 if (k .ge. 23) then x = 3*y k = k-1 go to 30 else x = y endif while( k >= 23) { x = 3* y; k -= 1; } x = y; Example of go to BECOMES

31. Early Software Engineering - 2 • Functional Decomposition • Help manage complexity of large software system by iteratively decomposing it into a series of increasingly detailed conceptualizations • Uses a structure chart to represent these conceptualizations (modules) and their interrelations. • Each module can be implemented using a function, process, or subroutine • Objectives: • Understand the software system abstractly • Use decomposition to produce well-structured software system • Used in Process-Oriented Paradigm

32. Example Structure Chart Book Tracking System Check Out Books Add new Book Report Lost Book Check in Book Reshelve Books Check for overdue Books Change Book Status Update Patron Information Update librarian work Information Update Reshelving list

33. What is missing • What data are shared amongst the modules • How modules interact with each other (we know which modules interact but not how) • This information is not recorded even it was discovered during the conceptualization process conceptualization representation implementation

34. Software Engineering - 3 • Structured Analysis and Design • First methodology: set of techniques that describe entire software development process . • Recognition that problem analysis and design of the software solution are important steps in the software development process. • Introduction of new modeling notation, data flow diagrams (DFD), which show • The sub processes that are invoked • The information that is transmitted between these sub processes (How they interact) • Used in Process-Oriented Paradigm

35. Partial Dataflow Diagram Write Patron record Patron record Patron ID Update Patron Information Check-inbooks True/false Patron record or null Book ID, in Patron ID Book ID Read Patronrecord Change bookstatus Read book record Book record Book record Update Reshelving List Book record Write book record

36. Software Engineering - 4 • Data-Centered Paradigm • Uses techniques developed in Structured Analysisbut extends it. First a central data depository (relational database) is designed using data modeling • Data modeling occurs using entity relationship (ER) diagrams before functional modelling (and before other software are developed) • After data modeling, applications using data from the central data repository can be developed • Such applications can be designed using structured analysis and design (or other development paradigms)

37. ER Diagrams • Original purpose was for the design of relational databases • ER Diagrams use boxes to denote entities. Entities are the things (abstract objects) than comprise the system. Entities can have attributes that describe their properties (data associated with them) • ER Diagrams use diamonds to denote relationships between entities. • ER Diagrams show • how entities are related to each other • Cardinality: how many instances of each kind of entities may join a relationship. (Notation differs)

38. Entity Relationship Diagram LibraryPatron 1 M Address Has-a 1 1 1 Requested by Checks out Has-a M M 1 1 M Book Has-a Publisher Assume the library has no more than 1 copy of each book

39. Example relationships • Each library patron can request or check out many books (arrow points to the single patron) relation is one patron to many books • Each book has one ISBN#, each ISBN number corresponds to one book, relation is one ISBN# to one book • Each library patron has a single address, but there may be more than one library patron with the same address. Relation is many patrons to one address

40. Software Engineering Methods - 5 • Object-oriented Paradigm • No longer segregates the modeling of functions and data • Objects aggregate data with functions that operate on the data

41. Principles of the OO Paradigm • Abstraction • Modularity • Modelling • Data Abstraction • Encapsulation • Inheritance • Polymorphism Sharedbyotherparadigms