Transcript Slide 1

Software Engineering,
CPSC-4360-01, CPSC-5360-01,
Lecture 1
Stefan Andrei
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
1
Software Engineering

CPSC-4360-01 and CPSC-5360-01 are 3 credits
points modules:

Midterm exam (Monday, March 14, 10:00am): 20%

CPSC-4360-01:


CPSC-5360-01:



Project: 30% (10% - Analysis & Design – Report, 20% Implementation & Test – Demonstration)
Project: 15% (5% - Analysis & Design – Report, 10% Implementation & Test – Demonstration)
Paper Presentation: 15%
Written final exam (May 9, 11:00am-1:30pm): 50%
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
2
Software Engineering

Module homepage


http://galaxy.lamar.edu/~sandrei/CPSC-4360-01/
Teaching

Lectures: Monday, Wednesday, Friday, 10:10-11:00,
MA111
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
3
Course Etiquette

Code of conduct
no copying
 for details, see webpage




You are encouraged to attend to all lectures,
tutorials, and so on.
You are encouraged to ask questions.
You are encouraged to offer answers.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
4
Consultation and Recommended Books

Dr. Stefan Andrei, [email protected] (please
send an email to make an appointment - MA2, #69)

Lectures based of the book (chapters available at the
course website):
 Bimlesh Wadhwa, Stefan Andrei, Soo Yuen Jien. Software
Engineering: An object-oriented approach. McGraw Hill,
2007, ISBN: 978-007-126610-9
Recommended books:





Mark Priestley: Practical Object-Oriented Design with UML, McGraw Hill, 2004
Ian Sommerville: Software Engineering, Pearson – Addison Wesley, 7th Edition,
2004
Craig Larman: Applying UML and Patterns, Pearson – Prentice Hall, 2005
Robert Binder: Testing Object-Oriented Systems, Addison Wesley, 2000
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
5
Overview of This Course


Software Development Process
Modelling with Objects





Design Model






Analysis Model
Use Case Modelling
Analysis Class Modelling
Object States
Design Class Modelling
Object Interactions
Implementation Issues
Testing and Integration
Design Patterns
Software Life Cycle Models / Methodologies
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
6
Tutorials Objectives

Purposes






7/7/2015
for self-assessment
use material from lectures
answer questions
help deep understanding
prepare projects
save your time!
CPSC-4360-01, CPSC-5360-01, Lecture 1
7
The Project
Students are given a problem specification


Vague, misleading, ambiguous, conflicting
It has two parts:


(i)
(ii)

(i)
(ii)


7/7/2015
Report
Sort out what to do
Sort out how to do it
Demonstration
Do it !
Verify
- analyse
- design
- code
- test
Group size is 3 or 4.
Strict deadline – the last week of teaching.
CPSC-4360-01, CPSC-5360-01, Lecture 1
8
Recommendations

For CPSC-4360-01 and CPSC-5360-01:

Walkthrough the software development process:





Best way to appreciate the course:



7/7/2015
Lectures give the theory background;
Tutorials allow you to explore the theory;
Project gives the opportunity to apply what you have
learned;
Furthermore, CPSC-5360-01 students need to present a
research paper presentation.
Read up relevant topics;
Attend the lectures and tutorials;
Do the relevant part for the project right after.
CPSC-4360-01, CPSC-5360-01, Lecture 1
9
Useful Software

Pre-requisites software:


Java Programming Language (http://java.sun.com/).
Recommended software:
 ArgoUML (http://argouml.tigris.org/) is a UML design

7/7/2015
tool with cognitive support, released on September,
2003;
JUnit (http://junit.sourceforge.net/) is a simple
framework to write repeatable tests, released on
August, 2002.
CPSC-4360-01, CPSC-5360-01, Lecture 1
10
Lecture Structure






Reminder of last lecture
Overview
Content (new notions + examples)
Summary
Reading suggestions
Coming up next
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
11
Overview of This Lecture

Overview of Software Engineering



Overview of Software Process


SE definitions
Quality of Good Software
Activities and associated stages
Overview of Software Engineering Method


7/7/2015
Structured Analysis
Object-Oriented Method
CPSC-4360-01, CPSC-5360-01, Lecture 1
12
What is ‘Software Engineering’?...
A term used occasionally in 1950s, 1960s
 Popularized in 1968 at NATO Software Engineering
Conference
(http://homepages.cs.ncl.ac.uk/brian.randell/NATO/)

7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
13
What is Software?



More than computer programs.
The collection of programs, documentation
and configuration data that ensures correct
execution.
Three major types:



7/7/2015
Generic Product: Stand alone, Sold on open
market.
Customized Product: For specific customer.
Embedded Product: Built into hardware.
CPSC-4360-01, CPSC-5360-01, Lecture 1
14
The Nature of Software

Intangible:



Easy to Reproduce:


Opposite of physical artifacts, e.g., Computer vs
Windows XP
Hard to understand the development process.
Costly design and construction, cheap
manufacturing.
Malleable:


7/7/2015
Easy to change, even without full understanding.
Untrained people can “hack” something together.
CPSC-4360-01, CPSC-5360-01, Lecture 1
15
Software Development Problems


“Software is not constrained by materials, or
governed by physical laws, or by
manufacturing process” ---- (Sommerville,
Software Engineering)
Allows almost unbounded complexity:


7/7/2015
Exponential growth of complexity w.r.t. to the size
of a program: twice the size, four times the
complexity;
Example: Windows XP has 40millions lines of
source code (estimation).
CPSC-4360-01, CPSC-5360-01, Lecture 1
16
Software Development Problems

Difficulty in understanding and managing the
complexity causes:

Late completion:


Overrunning Cost:




7/7/2015
“vaporware” that are announced but never produced
Denver Airport Automated Baggage System, 2 billions
US dollar over budget
Unreliable
Difficult to maintain
Etc…
CPSC-4360-01, CPSC-5360-01, Lecture 1
17
Famous Software Disaster

Ariane 5 expendable launch system:


Spacecraft launching system improved from
Ariane 4.
First test flight took place on June 4, 1996.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
18
Famous Software Disaster (cont)


US $5 hundred millions worth of payload
destroyed.
Reason:



7/7/2015
Main Navigation Computer crashes after 37
seconds.
Caused by a conversion overflow: converting
floating point number to integer number.
Reuse of specification of Ariane 4 without taking
into consideration the new capability.
CPSC-4360-01, CPSC-5360-01, Lecture 1
19
More Software Disasters



Denver Airport Automated Baggage System.
Therac-25: Massive overdose of radiation.
Link to History's Worst Software Bug:
http://wired.com/news/technology/bugs/0,69355-1.html?tw=wn_story_page_next1


http://www.comlab.ox.ac.uk/archive/safety.html
http://www.csl.sri.com/risks.html
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
20
What is Engineering?


Systematically identify, understand, and
integrate the constraints on a design to
produce a successful result.
Constraints may include:






available resources,
physical or technical limitations,
flexibility for future modifications and additions,
cost, manufacturability, and serviceability.
Deduce specifications from the limits.
Ethical Practices.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
21
Quality of Good Software

Usability


Efficiency


Reliable, secure and safe.
Maintainability


Does not waste resources such as CPU time and memory.
Dependability


Easy to learn and use.
Easily evolved (modified) to meet changing requirement.
Reusability

7/7/2015
Parts can be reused, with minor or no modification.
CPSC-4360-01, CPSC-5360-01, Lecture 1
22
Quality of Good Software

Can be quite different based on your viewpoint:
Customer:
User:
- Solves problems at
acceptable cost (time
and resource).
- Easy to learn
- Efficient to use
- Get work done
Developer Manager:
Developer:
- Sells more and
pleases customers
- Easy to design and
maintain
7/7/2015
- Costing less to
develop and maintain
CPSC-4360-01, CPSC-5360-01, Lecture 1
23
So, ‘Software Engineering’ is
IEEE Standard 610.12:
 The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software,
that is, the application of engineering to
software.
 “Designing, building and maintaining large
software systems”. - I. Sommerville
 “Multi-person construction of multi-version
software”. - D. L. Parnas
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
24
What is Software Engineering?...
“Technological and managerial discipline of software
products that are developed and modified on time and
within cost estimates”. – R. Fairley

“Software development is not simply a case of sitting
down at a terminal and typing in the program code”.

– M. Priestley
 A discipline that guides the process of solving
customers’ problems by the systematic development
and evolution of large, high-quality software systems
within cost, time and other constraints. – our definition
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
25
Software Engineering Myths

A general statement of objectives is sufficient
to begin writing programs - we can fill in the
details later.


If we get behind schedule, we can add more
programmers and catch up.

7/7/2015
Poor Up-front definition is the major cause
of failed software efforts.
Brooks Law: “Adding people to a late
project makes it later.”
CPSC-4360-01, CPSC-5360-01, Lecture 1
26
Software Engineering Myths

Project requirements continually change,
but change can be easily accommodated
because software is flexible.
Cost Impact
Severe
Moderate
Minor
Planning
7/7/2015
Design
Implementation
CPSC-4360-01, CPSC-5360-01, Lecture 1
Occurrence of
Change
27
Software Process

The steps involved in creating a software
system  Software Process.

The guideline or overall principle used during
the Software Process  Software
Engineering Method.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
28
Software Process


The set of activities and associated results
that produce a software product.
Four fundamental process activities:





Software Specification
Software Development
Software Validation
Software Evolution
Can be organized in different ways,
described at varying level of details →
different software development process
models (lecture 2).
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
29
Activity 1: Software Specification


Customers and Software Engineers
 Define the software to be produced
 Define the constraints on its operations
Typical Stages:
 Feasibility Study:


Domain Analysis:


Formal documentation on User and System requirements.
Requirements Validation:

7/7/2015
What is it that the user wants?
Requirements Specification:


What is the background for the software?
Requirements Gathering and Analysis:


Is it possible with the current technologies + within budget?
Check for realism, consistency, and completeness.
CPSC-4360-01, CPSC-5360-01, Lecture 1
30
Activity 2: Software Development


Consists of Design and Programming
System Analysts


Design: decide how the requirement can be
implemented.
Programmers

7/7/2015
Coding: translate high level design into real code
in a chosen programming language.
CPSC-4360-01, CPSC-5360-01, Lecture 1
31
Activity 2: Software Development
High
Level

Typical Stages (Design):


Architectural Design: Split into subsystems
Abstract Specification: High level specification on the
services and constraints for each subsystem

Interface Design: Interface with other subsystems are
defined

Component Design: Split the services and allocate to
components within a subsystem

Low
Level
7/7/2015

Data Structure Design: Choose appropriate data structure
Algorithm Design: Design and specify algorithm used to
provide services
CPSC-4360-01, CPSC-5360-01, Lecture 1
32
Activity 2: Software Development

Typical Stages (Programming):



7/7/2015
Data structure and algorithm design (from the
design stage) may be delegated to the
programmer.
Personal activity. Usually without a predefined
process.
Debugging: Low level testing of code. Reveals
program defects (bugs).
CPSC-4360-01, CPSC-5360-01, Lecture 1
33
Activity 3: Software Validation

Software Engineer (or dedicated tester) and Customer:


Typical Stages:




Check the software to ensure it meets the customers’
requirements.
Component Testing: Independent testing of individual
components in subsystem.
System Testing: Testing of integrated components. Can be
multi-levels, e.g., subsystem → system.
Acceptance Testing: Tested with customer supplied data. Final
test before operation.
Interactive activity that feedback to previous stages:

7/7/2015
E.g., an error in component testing triggers re-coding.
CPSC-4360-01, CPSC-5360-01, Lecture 1
34
Activity 4: Software Evolution

Customers and Software Engineers:



Define changing requirements.
Modify the software system to adapt.
Typical Work:


7/7/2015
Update the system for minor new requirements,
e.g., changing the telephone number from 7 digits
to 8 digits, changing the date representation (the
Millennium Bug).
Could be drastic, more like redevelopment, e.g.,
windows95 →windows98 → windowsXP.
CPSC-4360-01, CPSC-5360-01, Lecture 1
35
Simple Software Process Example

In the simplest cases, code is written directly
from some statements of requirements.
Process
Artifact
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
36
Simple Software Process Example
 Two processes:
 ‘Analyze requirements’
 ‘Write code’
 Two artifacts:
 ‘Requirements specification’
 ‘Source code’
 ‘Requirements specification’ can be written as:
 an informal outline or
 a highly detailed description.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
37
Simple Software Process Example

Software Specification:


Analyze Requirement → Requirement Documentation
Software Development:

Design:


Programming:



Write Code → Source Code
Debugging
Software Validation:


Data structure and algorithm
Compare against sample outputs
Software Evolution:

7/7/2015
Not applicable.
CPSC-4360-01, CPSC-5360-01, Lecture 1
38
A More Complex Software Process
It is better to design before you code.
 On larger projects, intermediate pieces of
documentation are produced.

7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
39
A More Complex Software Process
 One new process:
 ‘Design module structure’ - splitting the program
into modules and subroutines
 One new artifact:
 ‘Structure chart’ – is based on the information
contained in the ‘requirements specification’
 Both the ‘requirements specification’ and the
‘structure chart’ are used when writing the final
code.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
40
A More Complex Software Process

Software Specification:


Analyze Requirement → Requirement Documentation
Software Development:

Design:


Programming:



Write Code → Source Code
Debugging
Software Validation:


Structure Chart of the functions/modules/classes
Compare against sample outputs
Software Evolution:

7/7/2015
Not applicable.
CPSC-4360-01, CPSC-5360-01, Lecture 1
41
Modeling the System



The structure chart is an example of system
model.
A powerful and useful technique.
Give abstract view of the actual system




Usually in graphical notation
Easier to understand
Easier to manipulate
The semantic, usage and notation used in
modeling is part of Software Engineering
Method, described next.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
42
Software Engineering Method





A strategy for successfully developing
software.
A guiding principle throughout the Software
Process.
Based on the idea of developing graphical
models (abstract representation) of a system,
which can be used as specification or design.
No best method: depends on type of system.
Two popular methods are described next.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
43
Structured Analysis


One of the earliest methods, developed in 1970s.
Essence:



Function Oriented: Identify process (function) that
transform data.
Good match for procedural languages like C, Pascal,
Fortran, etc.
Example (Data Flow Diagram - DFD):
Stack
Push Value
on to Stack
Stack with
New Value
New
Value
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
44
Structured (Procedural) Methods





Structured methods = structured analysis and
structured design.
Characteristic model = data flow diagram (description
of the system’s data and how the data interact with
the system).
Structured methods refer to software systems where
data are processed by functions external to data.
In other words, the system’s data are stored in one
place, and functions (operations) are essentially
separated by the data.
Structured methods are appropriate for the design of
data-rich systems (e.g., relational databases).
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
45
Object-Oriented Methods


Recently developed in 1990s.
Essence:



Object-Oriented: Identify entity (object) that contains
natural collection of both data and the process (function)
that operates on them.
Good match for OO languages like C++, JAVA, SmallTalk,
etc.
Example (UML Class Diagram):
Stack
-Items: Integer[ ]
+push(value: integer)
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
46
Object-Oriented Methods



Most operations in real-world only use a small
fraction of the total data of the system, and
most pieces of data will be accessed by a small
number of operations.
So, there was a need to split the data
repository and integrate pieces of data with the
operations that directly manipulate those data =
object-oriented approaches.
Example: scanners and printers are (in)
separate (rooms), as they provide different
operations.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
47
Structured and Object-Oriented
Methods: Comparison



Compared with structured approaches, in the objectoriented approaches the operations are localized
together with the data that they affect, instead of
being part of a large and global structure.
Programs using object-oriented structures are easy to
understand and maintain (incremental software
development).
In the structured approach, each operation has the
responsibility of choosing the necessary data from the
central repository (i.e., global place where the data is
stored).
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
48
What’s in CPSC-4360 and CPSC-5360?


Subsequent lectures resemble a walkthrough of the
software development process using Object-Oriented
Method.
Software
Specification
Software
Development
Software
Validation
-Domain Analysis
-Requirements
Gathering and Analysis
-Requirements
Specification
-Requirements Validation
-Feasibility Study
-Architectural Design
-Abstract Specification
-Interface Design
-Component Design
-Data Structure Design
-Algorithm Design
-Component
Testing
-System Testing
-Acceptance Testing
Software
Evolution
-Maintenance
-Redevelopment
Those in Bold Font will be covered by lectures and project.
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
49
What’s NOT in CPSC-4360 and
CPSC-5360?

Aspects of Project Management:







Scheduling
Risk Assessment
Quality Assessment
Documentation
Human Resource Management
Etc….
Communication and Inter-Personal Skills:


7/7/2015
Other than communicating with your team mate and tutor
Not formally covered.
CPSC-4360-01, CPSC-5360-01, Lecture 1
50
Object Thinking
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
51
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
52
Class Representation: Example

Informal representation:

Define a class for representing students who


7/7/2015
can be identified by name
may be enrolled in some program of some level.
CPSC-4360-01, CPSC-5360-01, Lecture 1
53
Class Representation: Example
UML class
Student
- name : String
- program : String
- level : int
+ Student(n:String, p:String, lv:int)
+ printDetails() : void
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
54
Class Representation: Example
public class Student {
private String name;
private String program;
private int level;
public Student(String n, String p, int lv) {
name = n;
program = p; level = lv;
}
public void printDetails() {
System.out.println("\nDetails for student " + name);
System.out.println("\tProgram: " + program);
System.out.println("\tLevel: " + level);
}
}
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
55
Summary

Overview of Software Engineering



Overview of Software Process


SE definitions
Quality of Good Software
Activities and associated stages
Overview of Software Engineering Method


7/7/2015
Structured Analysis
Object-Oriented Method.
CPSC-4360-01, CPSC-5360-01, Lecture 1
56
Reading suggestions

From [Wadhwa, Andrei, Soo; 2007]


From [Priestley; 2004]




Chapter 1
Appendix A
Exercises 1.1-1.4
From [Sommerville; 2004]


Chapter 1
Chapters 1, 2
From [Larman; 2005]

7/7/2015
Chapter 1
CPSC-4360-01, CPSC-5360-01, Lecture 1
57
Coming up next


Software Development Process Models:

[Wadhwa, Andrei, Soo; 2007], Chapter 2

[Priestley, 2004], Chapter 3
UML Overview:

[Wadhwa, Andrei, Soo; 2007], Chapter 2

[Priestley, 2004], Chapters 1, 2
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
58
Thank you for your attention!
Questions?
7/7/2015
CPSC-4360-01, CPSC-5360-01, Lecture 1
59