CG152 Introduction: slide 1 CS223 Introduction: slide 1 CS223 Introduction to Software Engineering Doron Peled, Roger Packwood, Arshad Jhumka, Ananda Amatya,

CG152 Introduction: slide 1CS223 Introduction: slide 1

CS223 Introduction to Software Engineering

Doron Peled, Roger Packwood, Arshad Jhumka, Ananda Amatya,

Mike Joy

© The University of Warwick 1998-2005


Lecture 1 - Objectives

To introduce the staff

To explain the structure of the module

To describe what Software Engineering is about


Staff

Doron Peled

Roger Packwood

Arshad Jhumka

Ananda Amatya

Mike Joy


Timetable Lectures

– Weekly, weeks 1-10– Twice weekly, weeks 11-15

“Surgeries”– Weeks 6-19– Attend if you have any problems, or just questions you

wish to ask


Assessment

Exam (30%)

Group Project (70%)– Handout Wednesday 27 October (week 5)– deadline (part 1) Thursday 27 January (end week 14)– deadline (part 2) Thursday 10 March (end week 20)


Themes

General Software Engineering (Roger)

UML (Ananda)

Design Patterns (Arshad)

Project Management (Doron)

Formal Methods (Doron)

Coding Issues (Mike)

Software Engineering in Industry (IBM)


Lectures - Term 1 1 DP/RAP/AJ/AA Introduction2 RAP The Software Process3 RAP Software Specification4 AA UML: Overview5 DP/RAP/AJ/AA The Project + Tools6 AA Requirements (Use Case Modelling) 7 AA Analysis (Static & Dynamic Modelling)8 AJ Analysis To Design + Case Study (part 1)9 AJ Object Design + Case Study (part 2)10 MSJ Coding Issues


Lectures - Term 2 (provisional)

11 RAP Software Cost Estimation12 AJ Further Design + Case Study (part 3)13 DAP Formal Methods (1): Introduction14 DAP Formal Methods (2): Testing & Reliability15 IBMTeam Based Software Development16 IBMDevelopment Focus Areas & Practices17 RAP Safety-Critical Systems18 RAP Software Testing19 RAP Software Reliability20 AA Methodologies (XP)


Booklist See handout for ISBN, cost, etc. Recommended

– Bruegge and Dutoit General

– Pressman and Ince– Sommerville

UML– Bennett, Skelton and Lunn (Schaum)– Booch, Jacobson and Rumbaugh– Fowler and Scott

Others


General Software Engineering

Over to Roger ...


The Software Process Why is there a Software Process ?

– why not just write the program ? What the customer wants

– how it is implemented, or at least designed– change, for the better, sometimes ...

Why is software "engineering" hard ?– what solutions does "engineering" offer ?

The traditional software lifecycle– other development models


Software Specification "What" needs to be specified

– many people communicate via written documents

A specification that the customer can agree to– a specification for the programmer (one of many)

Many aspects (views) of a software design

Complete, Concise, Testable


Software Cost Estimation Before we even start, do we want the job ? Need to estimate -

– how much effort– how much time– how much money

Primarily based on how much last time– model based

Constructive Cost Model COCOMO Mythical Man Month - Brooks


Safety-Critical Systems Developing software that should never compromise the

overall safety of a system Reliability is with respect to specification

– safety is independent of specification Therac and Arianne examples Risk analysis

– intolerable– As Low As Reasonably Practical (ALARP)– acceptable

The Myths of Software Safety


Software Testing A successful test finds a fault

– testing does not prove the absence of faults White Box, Black Box testing Coverage testing, Exhaustive testing

– can you trust the test software? Test data values, Corner Cases, Fencepost errors

– mistyped variable names, operators, constructs Unit test, integration test, System, Alpha, Beta

– top-down, Bottom-up, Inside-out, Sandwich ??


Software Reliability Availability, Reliability, Safety, Integrity, etc.

Defects, Density and Zero

Fault Tolerance, N-Way, Recovery Blocks, Diversity

Dangerous Programming


OOD & UML

Over to Ananda ...


Bernd Bruegge, Adjunct, Carnegie Mellon UniversityAllen H. Dutoit, Technical University of Munich

ISBN: 0-13-191179-1

Publisher: Prentice HallCopyright: 2004Paperback 762 pages (November 30, 2003)

Amazon.co.uk Price: £35.99

Warwick Bookshop: In stock


Objectives (with lecture & suggested reading plan) Understand System Modelling Learn UML (Unified Modelling Language) (Lecture 4: BD ch. 2) Learn different modelling methods:

– Use Case modelling (Requirements Elicitation) (Lecture 6: BD ch. 4)– Static & Dynamic modelling (Domain Analysis) (Lecture 7: BD ch. 5)

Learn how to use Tools:– CASE (Computer Aided Software Engineering) Tool:

IBM Rational Rose (Lecture 5: with Project Lecture) Learn Software Development Methodologies: (Lecture 20: BD ch. 16)

– Rational Unified Process– Agile Process (XP)


Factors affecting the quality of a software system

Complexity:– System too complex for a single programmer to comprehend;– Fixing one bug introduces another bug.

Change: – Entropy of a software system increases with each change:

Change in a system alters its structureChange in structure makes the next change more

difficult.– Cost of subsequent changes increase rapidly:

Whatever the system’s application domain or technological base.


Dealing with Complexity

Abstraction

Decomposition

Hierarchy


Abstraction

Inherent human limitation to deal with complexity– The 7 +- 2 phenomena

Chunking: – Group collection of objects

Ignore unessential details: – Models


Models are used to provide abstractions

System Model:– Object Model: system structure; object interaction– Functional model: system functions; data flow through the system– Dynamic model: system reaction to external events; event flow

Task Model:– PERT Chart: dependencies between the tasks– Schedule: time limit– Org Chart: roles in the project or organization

Issues Model:– Open and closed issues; – constraints posed by the client; – resolutions made.


Which decomposition is the right one?

Decomposition A technique used to master complexity (divide and conquer) Functional decomposition

– system decomposed into modules– Module: a major processing step (function) in the application domain– Modules can be decomposed into smaller modules

Object-oriented decomposition– The system is decomposed into classes (objects) – Each class is a major abstraction in the application domain– Classes can be decomposed into smaller classes


Class Identification Object-oriented modelling requires Class identification:

– Finding classes for a new software system (Greenfield Engineering)– Identifying classes in an existing system (Reengineering)– Creating class-based interface to a system (Interface Engineering)

Class identification uses:– Philosophy – Science– Experimental evidence

Difficulty in identifying classes:– Determining the purpose of a system


Hierarchy

Abstraction & Decomposition:– Leads to classes & objects (object model)

Relationships between classes & objects– Structure (static models), interactions (dynamic models)– Hierarchical relationships between classes

2 important hierarchies– "Part of" hierarchy– "Is-kind-of" hierarchy


Part of HierarchyComputer

Cache ALU Program Counter

I/O Devices CPU Memory


Is-Kind-of Hierarchy (Taxonomy)Cell

Muscle Cell Blood Cell Nerve Cell

Striate Smooth Red White Cortical Pyramidal


So where are we right now? Three ways to deal with complexity:

– Abstraction – Decomposition– Hierarchy

Object-oriented decomposition is a good methodology– Difficulty in determining the purpose of a system– Depending on the purpose, different objects are found

How can we do it right? – Many different possibilities– Use Case Modelling (currently popular) approach:

Start with a description of the functionalityThen proceed to the object modelThis leads us to the software lifecycle


Software Lifecycle Activities

Use CaseModel

Solution Domain Objects

Realized By

ApplicationDomain Objects

Expressed in Terms Of

Test Cases

?

Verified By

class.... ?

Subsystems

Structured By

class...class...class...

SourceCode

Implemented By

SystemDesign

ObjectDesign

Implemen-tation

TestingRequirements

ElicitationAnalysis

...and their models


OOD & UML

Over to Arshad ...


Reusability … living with change A good software design solves a specific problem but is

general enough to address future problems (for example, changing requirements)

Experts do not solve every problem from first principles– They reuse solutions that have worked for them in the past

Goal for the software engineer:– Design the software to be reusable across application

domains and designs How?

– Use design patterns and frameworks whenever possible


Design Patterns and Frameworks

Design Pattern: – A small set of classes that provide a template solution to a

recurring design problem– Reusable design knowledge on a higher level than

datastructures (link lists, binary trees, etc) Framework:

– A moderately large set of classes that collaborate to carry out a set of responsibilities in an application domain. Examples: User Interface Builder

Provide architectural guidance during the design phase Provide a foundation for software components industry


Patterns are used by many people Chess Master:

– Openings

– Middle games

– End games Writer

– Tragically Flawed Hero (Macbeth, Hamlet)

– Romantic Novel

– User Manual Architect

– Office Building

– Commercial Building

– Private Home

Software Engineer

– Composite Pattern: A collection of objects needs to be treated like a single object

– Adapter Pattern (Wrapper): Interface to an existing system

– Bridge Pattern: Interface to an existing system, but allow it to be extensible

Now Read Chapter 1 of BD book


Chapter 1: Introduction


Coding Issues● Mike will talk about how to write good Java code?● His lecture will include topics such as:

– packages– inheritance– subclassing– interface– modifiers– exception handling– accessor methods– abstract classes– Java Beans


Finally

Back to Doron ...


Goal: software reliabilityUse software engineering

methodologies to develop the code.

Use formal methods during code development


What are formal methods?

Techniques for analyzing systems, based on some mathematics.

This does not mean that the user must be a mathematician.

Some of the work is done in an informal way, due to complexity.


Examples for FMDeductive verification:

Using some logical formalism, prove formally that the software satisfies its specification.

Model checking:Use some software to automatically check that the software satisfies its specification.

Testing:Check executions of the software according to some coverage scheme.


Typical situation: Boss: Mark, I want that the new internet marketing software

will be flawless. OK?

Mark: Hmmm. Well, ..., Aham, Oh! Ah??? Where do I start?

Bob: I have just the solution for you. It would solve everything.


Some concerns• Which technique?• Which tool?• Which experts?• What limitations?• What methodology?• At which points?• How expensive?• How many people?

• Needed expertise.• Kind of training.• Size limitations.• Exhaustiveness.• Reliability.• Expressiveness.• Support.


Common critics

Formal methods can only be used by mathematicians.

The verification process is itself prone to errors, so why bother?

Using formal methods will slow down the project.


Some questions and answers...Formal methods can only be used by mathematicians.Wrong. They are based on some math but the user

should not care.

The verification process is itself prone to errors, so why bother?

We opt to reduce the errors, not eliminate them.

Using formal methods will slow down the project.Maybe it will speed it up, once errors are found

earlier.


Some exaggerationsAutomatic verification can always find errors.Deductive verification can show that the

software is completely safe.Testing is the only industrial practical method.


Our approach

Learn several methods (deductive verification, model checking, testing process algebra).

Learn advantages and limitations, in order to choose the right methods and tools.

Learn how to combine existing methods.


EmphasisThe process:

Selecting the tools, Modeling,Verification, Locating errors.

Use of tools:Hands on. PVS, SPIN

Visual notation:Statecharts, MSCs, UML.


Some emphasisThe process of selecting and using formal

methods.

The appropriate notation. In particular, visual notation.

Hands-on experience with tools.


SummaryIn this lecture, we have: Discussed the administrative arrangements Mentioned the topics we will cover in detail

Please ... Consult Web Site for information

http://www.dcs.warwick.ac.uk/people/academic/Doron.Peled/course/cs223/index.html

Subscribe to newsgroupuwarwick.dcs.course.cs223


End

Documents

CG152 Introduction: slide 1 CS223 Introduction: slide 1 CS223 Introduction to Software Engineering Doron Peled, Roger Packwood, Arshad Jhumka, Ananda Amatya,