CS223 Introduction to Software Engineering - Computer Science

lumpysteerΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

92 εμφανίσεις

CG152 Introduction: slide 1

CS223 Introduction: slide 1

CS223 Introduction to Software
Engineering

Doron Peled, Roger Packwood,

Arshad Jhumka, Ananda Amatya,

Mike Joy


© The University of Warwick 1998
-
2005

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Lecture 1
-

Objectives




To introduce the staff


To explain the structure of the module


To describe what Software Engineering is about

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Staff



Doron Peled


Roger Packwood


Arshad Jhumka


Ananda Amatya


Mike Joy

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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


CG152 Introduction: slide 1

CS223 Introduction: slide 1

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)

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Themes



General Software Engineering (Roger)


UML (Ananda)


Design Patterns (Arshad)


Project Management (Doron)


Formal Methods (Doron)


Coding Issues (Mike)


Software Engineering in Industry (IBM)


CG152 Introduction: slide 1

CS223 Introduction: slide 1

Lectures
-

Term 1



1


DP/RAP/AJ/AA

Introduction

2


RAP



The Software Process

3


RAP



Software Specification

4


AA



UML: Overview

5


DP/RAP/AJ/AA

The Project + Tools

6


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


CG152 Introduction: slide 1

CS223 Introduction: slide 1

Lectures
-

Term 2 (provisional)


11

RAP

Software Cost Estimation

12

AJ

Further Design + Case Study (part 3)

13

DAP

Formal Methods (1): Introduction

14

DAP

Formal Methods (2): Testing & Reliability


15

IBM

Team Based Software Development

16

IBM

Development Focus Areas & Practices

17

RAP

Safety
-
Critical Systems


18

RAP

Software Testing


19

RAP

Software Reliability

20

AA

Methodologies (XP)



CG152 Introduction: slide 1

CS223 Introduction: slide 1

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


CG152 Introduction: slide 1

CS223 Introduction: slide 1

General Software Engineering




Over to Roger ...

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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 ??


CG152 Introduction: slide 1

CS223 Introduction: slide 1

Software Reliability


Availability, Reliability, Safety, Integrity, etc.


Defects, Density and Zero


Fault Tolerance, N
-
Way, Recovery Blocks, Diversity


Dangerous Programming

CG152 Introduction: slide 1

CS223 Introduction: slide 1

OOD & UML




Over to Ananda ...

CG152 Introduction: slide 1

CS223 Introduction: slide 1



Bernd Bruegge,
Adjunct, Carnegie
Mellon University

Allen H. Dutoit,
Technical
University of Munich



ISBN: 0
-
13
-
191179
-
1



Publisher: Prentice Hall

Copyright: 2004

Paperback 762 pages (November
30, 2003)



Amazon.co.uk Price: £35.99



Warwick Bookshop: In stock


CG152 Introduction: slide 1

CS223 Introduction: slide 1

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)

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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 structure


Change in structure makes the next change more
difficult.


Cost

of subsequent changes increase rapidly:


Whatever the system’s application domain or
technological base.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Dealing with Complexity


Abstraction



Decomposition



Hierarchy


CG152 Introduction: slide 1

CS223 Introduction: slide 1

Abstraction


Inherent human limitation to deal with
complexity


The 7 +
-

2 phenomena



Chunking:


Group collection of
objects



Ignore unessential details:



Models


CG152 Introduction: slide 1

CS223 Introduction: slide 1

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.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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


CG152 Introduction: slide 1

CS223 Introduction: slide 1

Class Identification


Object
-
oriented modelling requires Class identification:


Finding
classes

for a new software system

(Greenfield Engineering)


Identifying
classes

in an existing system (
Reengineering
)


C
reating 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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Part of Hierarchy

Computer

Cache

ALU

Program


Counter

I/O Devices

CPU

Memory

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Is
-
Kind
-
of Hierarchy (Taxonomy)

Cell

Muscle Cell

Blood Cell

Nerve Cell

Striate

Smooth

Red

White

Cortical

Pyramidal

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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
functionality


Then proceed to the
object model


This leads us to the
software lifecycle

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Software Lifecycle Activities

Use Case

Model

Solution
Domain

Objects

Realized By

Application

Domain

Objects

Expressed in Terms
Of

Test

Cases

?

Verified

By

class....

?

Subsystems

Structured By

class...

class...

class...

Source

Code

Implemented


By

System

Design

Object

Design

Implemen
-

tation

Testing

Requirements

Elicitation

Analysis

...and their models

CG152 Introduction: slide 1

CS223 Introduction: slide 1

OOD & UML




Over to Arshad ...

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Chapter 1: Introduction

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Finally




Back to Doron ...

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Goal: software reliability

Use software engineering
methodologies to develop
the code.

Use formal methods during
code development

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Examples for FM

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

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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.



CG152 Introduction: slide 1

CS223 Introduction: slide 1

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.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Some exaggerations

Automatic verification can always find errors.

Deductive verification can show that the
software is completely safe.

Testing is the only industrial practical method.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

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.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Emphasis

The process
:

Selecting the tools, Modeling,

Verification, Locating errors.


Use of tools
:

Hands on. PVS, SPIN


Visual notation
:

Statecharts, MSCs, UML.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Some emphasis

The process of selecting and using formal
methods.


The appropriate notation. In particular, visual
notation.


Hands
-
on experience with tools.

CG152 Introduction: slide 1

CS223 Introduction: slide 1

Summary

In 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 newsgroup

uwarwick.dcs.course.cs223

CG152 Introduction: slide 1

CS223 Introduction: slide 1

End