Software Engineering (CPSC-4360),

Lesson 1

Stefan Andrei

1/4/2012

CPSC-4360, Lesson 1

Consultation and Recommended Books

Dr. Stefan Andrei, StefanAndrei@cs.lamar.edu
Lectures based on the textbook:

Mark Priestley: Practical Object-Oriented Design with UML,

McGraw Hill, 2004, ISBN: 9780077103934

Recommended books:

Bimlesh Wadhwa, Stefan Andrei, Soo Yuen Jien: Software Engineering: An

object-oriented approach. McGraw Hill, 2007, ISBN: 978-007-126610-9
Ian Sommerville: Software Engineering, Pearson Addison Wesley, 9th Edition,
2011, ISBN: 9780137035151
Craig Larman: Applying UML and Patterns, Pearson Prentice Hall, 2005,
ISBN: 9780131489066
Robert Binder: Testing Object-Oriented Systems, Addison Wesley, 2000, ISBN:
9780321700674

1/4/2012

CPSC-4360, Lesson 1

Overview of This Course

Introduction to Software Engineering

Software Development Models
Use Case and Domain Modeling
Object-Oriented Analysis
Design (class and object diagrams, class generalization and
association classes, interaction diagrams)
State diagrams
Design Patterns
Design to Implementation and Essentials of Java Programming
Language
Software Testing and Automated Test Driver; Test Case Design
Professional Ethics, Responsibilities, and Social Implications of
Software Engineering

1/4/2012

CPSC-4360, Lesson 1

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

1/4/2012

Structured Analysis
Object-Oriented Method

CPSC-4360, Lesson 1

What is Software Engineering?...

A

term used occasionally in 1950s and 1960s.

Popularized in 1968 at NATO Software Engineering
Conference
(http://homepages.cs.ncl.ac.uk/brian.randell/NATO/)
Because of the need of large and high quality
software systems, software engineering techniques
are needed.
Large systems cannot be completely understood by
one person, instead teamwork and co-ordination are
required.

1/4/2012

CPSC-4360, Lesson 1

What is Software?
More than computer programs.
The collection of programs, documentation
and configuration data that ensures correct
execution.
Three major types:

1/4/2012

Generic Product: Stand alone, Sold on open

market.
Customized Product: For specific customer.
Embedded Product: Built into hardware.

CPSC-4360, Lesson 1

The Nature of Software

Intangible:

Easy to Reproduce:

Opposite of physical artifacts, e.g., Computer

versus Windows XP
Hard to understand the development process.
Costly design and construction, cheap
manufacturing.

Malleable:

1/4/2012

Easy to change, even without full understanding.

Untrained people can hack something together.
CPSC-4360, Lesson 1

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:

1/4/2012

Exponential growth of complexity with respect 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, Lesson 1

Software Development Problems

Difficulty in understanding and managing the

complexity causes:

Late completion:

Overrunning Cost:

1/4/2012

Many features that are announced but never produced

Denver Airport Automated Baggage System, 2 billions
US dollar over budget

Unreliable
Difficult to maintain
Etc
CPSC-4360, Lesson 1

Known Software Disaster

Ariane 5 expendable launch system:

Spacecraft launching system improved from

Ariane 4.

First test flight took place on June 4, 1996.

1/4/2012

CPSC-4360, Lesson 1

10

Known Software Disaster (cont)

US $5 hundred millions worth of payload
destroyed.
Reason:

1/4/2012

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, Lesson 1

11

More Software Disasters

The Denver Airport Automated Baggage System.
The Therac-25: Massive overdose of radiation.
The History's Worst Software Bug:

http://wired.com/news/technology/bugs/0,69355-1.html?tw=wn_story_page_next1

Websites containing lists of software disasters and

risks:

http://www.comlab.ox.ac.uk/archive/safety.html
http://www.csl.sri.com/risks.html

1/4/2012

CPSC-4360, Lesson 1

12

What is Engineering?
Engineering means to 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.

1/4/2012

CPSC-4360, Lesson 1

13

Quality of Good Software

Usability

Efficiency

Reliable, secure and safe.

Maintainability

Does not waste resources such as Central Processing Unit

(CPU) time and memory.

Dependability

Easy to learn and use.

Easily evolved (modified) to meet changing requirement.

Reusability

1/4/2012

Parts can be reused, with minor or no modification.

CPSC-4360, Lesson 1

14

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

1/4/2012

- Costing less to
develop and maintain
CPSC-4360, Lesson 1

15

So, Software Engineering is

According to the 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
1/4/2012

CPSC-4360, Lesson 1

16

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

1/4/2012

CPSC-4360, Lesson 1

17

Software Engineering Myths

A general statement of objectives is sufficient
to begin writing programs - we can fill in the
details later. This is not true because:

Poor Up-front definition is the major cause

of failed software efforts.

If we get behind schedule, we can add more

programmers and catch up. This is not true
because:

1/4/2012

Brooks Law: Adding people to a late

project makes it later.
CPSC-4360, Lesson 1

18

Software Engineering Myths

It is true that software is flexible compared with hardware.

On the other hand, if the program requirements change
when the project is already in the late phases of software
development (e.g., implementation, testing), then the cost
impact is severe.
Cost Impact
Severe
Moderate
Minor
Planning
1/4/2012

Design

Implementation

CPSC-4360, Lesson 1

Occurrence of
Change
19

Software Process

The steps involved in creating a software

system is called the Software Process.

The guideline or overall principle used during

the Software Process is called the Software
Engineering Method.

1/4/2012

CPSC-4360, Lesson 1

20

A Software Process is
the set of activities and associated results
that produce a software product.
It has four fundamental process activities:

Software Specification
Software Development
Software Validation
Software Evolution

Can be organized in different ways with

varying level of details.
Different software development process
models are presented in Lecture 2.

1/4/2012

CPSC-4360, Lesson 1

21

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:

1/4/2012

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 and within budget?

Check for realism, consistency, and completeness.

CPSC-4360, Lesson 1

22

Activity 2: Software Development

Consists of Design and Programming.
System Analysts

Design: decide how the requirement can be

implemented.

Programmers

1/4/2012

Coding: translate high level design into real code

in a chosen programming language.

CPSC-4360, Lesson 1

23

Activity 2: Software Development (cont)

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 is

defined

Component Design: Split the services and allocate them to

components within a subsystem

Low
Level

Data Structure Design: Choose an appropriate data

structure

Algorithm Design: Design and specify the algorithm used

to provide services.

1/4/2012

CPSC-4360, Lesson 1

24

Activity 2: Software Development (cont)

Typical Stages (Programming):

1/4/2012

Data structure and algorithm design (from the

design stage) may be delegated to the
programmer.
It is a personal activity, usually without a
predefined process.
It includes debugging at a low level testing of
code. It reveals program defects (bugs).

CPSC-4360, Lesson 1

25

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:

1/4/2012

E.g., an error in component testing triggers re-coding.

CPSC-4360, Lesson 1

26

Activity 4: Software Evolution

Customers and Software Engineers:

Typical Work:

Define changing requirements;

Modify the software system to adapt.
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.,

Windows XP Windows Vista Windows 7.

1/4/2012

CPSC-4360, Lesson 1

27

Simple Software Process Example

In the simplest cases, the code is written directly

from some statements of requirements.
Process

Artifact

1/4/2012

CPSC-4360, Lesson 1

28

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.
1/4/2012

CPSC-4360, Lesson 1

29

Simple Software Process Example

Software Specification:

Do the Requirements Analysis and create the Requirement

Documentation.

Software Development:

Design:

Programming:

Write Code into Source Code;

Debugging.

Software Validation:

Data structure and algorithm.

Compare against sample outputs.

Software Evolution:

1/4/2012

Not applicable.
CPSC-4360, Lesson 1

30

A More Complex Software Process

It is better to design before you code.
On larger projects, intermediate pieces of
documentation are produced.

1/4/2012

CPSC-4360, Lesson 1

31

A More Complex Software Process

Compared with the simple software process,
there is:
One new process: Design module structure
means splitting the program into modules and
subroutines.
One new artefact: 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.
1/4/2012

CPSC-4360, Lesson 1

32

A More Complex Software Process

Software Specification:

Do the Requirements Analysis and create the Requirement

Documentation.

Software Development:

Design:

Programming:

Write Code into Source Code;

Debugging.

Software Validation:

Structure Chart of the functions/modules/classes;

Data structure and algorithm.

Compare against sample outputs.

Software Evolution:

1/4/2012

Not applicable.
CPSC-4360, Lesson 1

33

Modeling the System

The structure chart is an example of system
model that appears in the complex software
process.
The model gives an abstract view of the actual
system:

Usually in graphical notation;

Easier to understand;
Easier to manipulate.

The semantics, usage, and notation used in

modeling is part of the Software Engineering
Method, described next.

1/4/2012

CPSC-4360, Lesson 1

34

A Software Engineering Method

.. is a strategy for successfully developing
software.
is a guiding principle throughout the
Software Process.
is based on the idea of developing graphical
models (abstract representation) of a system,
which can be used as specification or design.
There is no best method: it depends on the
type of system.
Two popular methods are described next.

1/4/2012

CPSC-4360, Lesson 1

35

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
1/4/2012

CPSC-4360, Lesson 1

36

Structured (Procedural) Methods

Structured methods = structured analysis and

structured design.
Characteristic model = data flow diagram (description
of the systems 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 systems 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).

1/4/2012

CPSC-4360, Lesson 1

37

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 object-oriented languages like C++,
JAVA, SmallTalk, etc.

Example (UML Class Diagram):

Stack
-Items: Integer[ ]
+push(value: integer)

1/4/2012

CPSC-4360, Lesson 1

38

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 together with the
operations that directly manipulate those data.
This is the main principle of object-oriented
approaches.
Example: scanners and printers are (in) separate
(rooms), as they provide different operations.

1/4/2012

CPSC-4360, Lesson 1

39

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 repository.
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 a
central repository (i.e., global place where the data is
stored).

1/4/2012

CPSC-4360, Lesson 1

40

Object-oriented versus traditional

On a table, there are few apples, peaches, and

pineapples.
In a shelf, there are three different knives for cutting
apples, peaches, and pineapples, respectively.
Traditional approach:

The person who wants to cut some of the above fruits has the
responsibility to choose that fruit and its corresponding knife.

Object-oriented approach:

1/4/2012

The table is splitted in three separate sections, the first one with
apples and their knife, the second one with peaches and their knife,
and the third one with pineapples and their knife.
The person who wants to cut and eat a fruit will choose the desired
section which has that fruit and its knife.
CPSC-4360, Lesson 1

41

Whats in Software Engineering course?

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.

1/4/2012

CPSC-4360, Lesson 1

42

Whats NOT in the Software

Engineering course?

Aspects of Project Management:

Scheduling
Risk Assessment
Quality Assessment
Documentation
Human Resource Management
Etc.

Communication and Inter-Personal Skills:

1/4/2012

Other than communicating with your team mate and tutor

Not formally covered.
CPSC-4360, Lesson 1

43

Class Representation: Example

Informal representation:

Define a class for representing students who

1/4/2012

can be identified by name

may be enrolled in some program of some level.

CPSC-4360, Lesson 1

44

Class Representation: Example

A UML Class Icon
Student
- name : String
- program : String
- level : int
+ Student(n:String, p:String, lv:int)
+ printDetails() : void

1/4/2012

CPSC-4360, Lesson 1

45

A Java Code for the previous Class Icon

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);
}
}
1/4/2012

CPSC-4360, Lesson 1

46

Summary

Overview of Software Engineering

Overview of Software Process

SE definitions;
Quality of Good Software.
Activities and associated stages.

Overview of Software Engineering Method

1/4/2012

Structured Analysis;
Object-Oriented Method.

CPSC-4360, Lesson 1

47

Reading suggestions

From [Priestley; 2004]

Chapter 1
Appendix A
Exercises 1.1-1.4

From [Wadhwa, Andrei, Soo; 2007]

1/4/2012

Chapter 1

CPSC-4360, Lesson 1

48

Coming up next

Software Development Process Models:

[Priestley, 2004], Chapter 3

[Wadhwa, Andrei, Soo; 2007], Chapter 2

UML Overview:

1/4/2012

[Priestley, 2004], Chapters 1, 2

[Wadhwa, Andrei, Soo; 2007], Chapter 2

CPSC-4360, Lesson 1

49

Thank you for your attention!

Questions?

1/4/2012

CPSC-4360, Lesson 1

50