CMPT 275 Software Engineering Introduction 1 Important Topics

CMPT 275 Software Engineering Introduction 1

Important Topics ] Why is Software Engineering Important? ] What is Software Engineering? u a brief historical review ] Software Engineering Methods/Concepts/Activities ] Various Software Development Paradigms ] What makes a “Good” Software System? Janice Regan, 2008 2

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 u What if you transferred money between accounts electronically and it disappeared without a trace? u What if the medical scanning equipment malfunctioned and gave you a critical dose of radiation? u Other examples? Janice Regan, 2008 3

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! Janice Regan, 2008 4

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. Janice Regan, 2008 5

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 Janice Regan, 2008 6

Therac 25: Actual problem ] In truth there was 1 problem, a race condition: u Magnets to tailor dose for patient needed to be moved as each treatment was set up u 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 Janice Regan, 2008 7

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

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 u Clear interfaces between the units must be defined and adhered to Janice Regan, 2008 9

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 u 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 Janice Regan, 2008 10

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

Sources of Complexity ] The size of the software development project u Difficult to keep track of all the details of large software project without formal processes u 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. Janice Regan, 2008 12

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

Communication Breakdown: ] Software developers and end users have u different background knowledge u different vocabulary Application domain vocabulary (medical, scientific, business …) Different from software developers technical vocabulary u In some areas a “Business Analyst” role bridges this gap u In other areas a person who speaks both ‘languages’ is needed Janice Regan, 2008 14

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. ” Janice Regan, 2008 15

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

Design for easy Maintenance ! ] A software system that is difficult to maintain may be unsuccessful when put into production u 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 u 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 Janice Regan, 2008 17

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

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. ” Janice Regan, 2008 From http: //www. practicalprocess. com/seyp/definition. html 19

Objective of Software Engineering ] To organize and control software development process and produce a wellstructured, accurate and useful software solution. Janice Regan, 2008 20

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

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 Janice Regan, 2008 22

Modeling ] Models can also be used to: u Assess the practicality and usefulness of the system u Estimate the cost and development time of the system u Develop a implementable approach to building the system with the desired functionality u And more … Janice Regan, 2008 23

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

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 ] u Design and documentation is a waste of time u Production of lines of source code (# of LOC) or implementation of numbers of features as the sole measures of progress of project u End users should only be involved at the beginning and end of the software development process. OR u End users can add requests for additional functionality at any time Poor project estimation, unreasonable deadlines u Causes programmers to cut corners, omit documentation, ‘patch’ or ‘hack’ rather than design and implement u Leads to maintenance nightmares Janice Regan, 2008 25

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. Janice Regan, 2008 26

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 Janice Regan, 2008 27

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 Janice Regan, 2008 28

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

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

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

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

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 Janice Regan, 2008 33

Software Engineering - 3 ] Structured Analysis and Design u First methodology: set of techniques that describe entire software development process. u Recognition that problem analysis and design of the software solution are important steps in the software development process. u 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) u Used in Process-Oriented Paradigm Janice Regan, 2008 34

Partial Dataflow Diagram Write Patron record Update Patron Information Patron ID Read Patron record Patron ID True/false Patron record or null Check-in books Book ID, in Change book status Book record Janice Regan, 2008 Write book record Book ID Read book record Book record Update Reshelving List 35

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

ER Diagrams ] Original purpose was for the design of relational databases ] ER Diagrams use boxes to denote entities. Entities are 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 u how entities are related to each other u Cardinality: how many instances of each kind of entities may join a relationship. (Notation differs) Janice Regan, 2008 37

Entity Relationship Diagram Library Patron 1 M Has-a 1 1 Checks out 1 Requested by Has-a M M Book Address 1 M Has-a 1 Publisher Assume the library has no more than 1 copy of each book Janice Regan, 2008 38

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 Janice Regan, 2008 39

Software Engineering Methods - 5 ] Object-oriented Paradigm u No longer segregates the modeling of functions and data u Objects aggregate data with functions that operate on the data Janice Regan, 2008 40

Principles of the OO Paradigm ] Abstraction ] Modularity ] Modelling Shared by other paradigms ] Data Abstraction ] Encapsulation ] Inheritance ] Polymorphism Janice Regan, 2008 41