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?
Janice Regan, 2008 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?
Janice Regan, 2008 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!
Janice Regan, 2008 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.
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 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.
Janice Regan, 2008 12
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
Janice Regan, 2008 13
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
Janice Regan, 2008 14
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
Janice Regan, 2008 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.”
Janice Regan, 2008 16
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
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 20
Objective of Software Engineering
To organize and control software development process and produce a well-structured, accurate and useful software solution.
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 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 …
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 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.
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 30
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
Janice Regan, 2008 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
Janice Regan, 2008 32
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
Janice Regan, 2008 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
Janice Regan, 2008 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
Janice Regan, 2008 35
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
Janice Regan, 2008 36
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
Janice Regan, 2008 37
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
Janice Regan, 2008 38
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
Janice Regan, 2008 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
Janice Regan, 2008 40
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
Janice Regan, 2008 41
Principles of the OO Paradigm Abstraction
Modularity
Modelling
Data Abstraction
Encapsulation
Inheritance
Polymorphism
Shared by other paradigms