1 cmpt 275 software engineering introduction. janice regan, 2008 2 important topics why is software...

1

CMPT 275Software Engineering

Introduction

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


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?


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!


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.


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


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


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


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


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


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.


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.

Sources of Complexity


Communication Breakdown: 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


Communication Breakdown: 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 other areas a person who speaks both ‘languages’ is needed


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.”


Communication Breakdown: 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


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


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


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


Objective of Software Engineering

To organize and control software development process and produce a well-structured, accurate and useful software solution.


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


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


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 …


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


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


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.


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


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


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

http://www.acm.org/classics/oct95/www.cs.pdx.edu/~apt/cs302_1999/lecture5/lecture5.htmlwww.azillionmonkeys.com/qed/goto.html




Example of go to30 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;

BECOMES


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


Example Structure Chart Book

Tracking System

Check OutBooks

Check inBook

Add new Book

Report LostBook

ReshelveBooks

Check foroverdueBooks

Update librarian work

Information

ChangeBook Status

Update Patron

Information

Update Reshelving list


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


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


Partial Dataflow Diagram

Update PatronInformation

Check-inbooks

Read Patronrecord

Change bookstatus

Read book record

Write book record

Patron ID

True/false

Patron IDPatron recordor null

Book ID, in

Book ID

Book recordBook record

Write Patron record

Patron record

Update Reshelving

List

Book record


Data-Centered Paradigm Uses techniques developed in Structured Analysis

but 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)

Software Engineering - 4


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)

ER Diagrams


Entity Relationship Diagram

Checks out

LibraryPatron Address

Book Publisher

Requestedby

1

M

Has-a

Has-a

Has-a

Assume the library has no morethan 1 copy of each book

1

1

1

M

1

M

1

M


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


Object-oriented Paradigm

No longer segregates the modeling of functions and data

Objects aggregate data with functions that operate on the data

Software Engineering Methods - 5


Principles of the OO Paradigm Abstraction

Modularity

Modelling

Data Abstraction

Encapsulation

Inheritance

Polymorphism

Shared by other paradigms

1 cmpt 275 software engineering introduction. janice regan, 2008 2 important topics why is software...

Documents