Вы находитесь на странице: 1из 123

Modern Methods in Software Engineering

ID2207

Introduction

www.imit.kth.se/courses/2G1522

Course info

www.imit.kth.se/courses/2G1522

Coordinator and lecturer Mihhail Matskin misha@imit.kth.se tel. 08-790 41 28

Assignments and project responsible

Nima Dokoohaki

Shahab Mokarizadeh

nimad@kth.se shahab@kth.se Lectures & Exercises:

Mondays 10.00-12.00

13.00-15.00

Fridays 10.00-12.00 Written examination ( 4.5 p.) October 18 at 09:00-13:00 Registration at least 14 days before exam period Homework and project assignments (3 p.)

Homework

Start Date

2010-09-13

2010-09-20

2010-09-27

2010-10-04

It is assumed that the Homework are done by groups of 2 student - there will be no additional bonus for doing them alone

Due Date

2010-09-19

2010-09-26

2010-10-03

2010-10-10

Description

Homework 1 Homework 2 Homework 3 Homework 4

Aims of the project

Project

• To get practice in Agile Programming approach

Your task

Apply some elements of Extreme programming approach to solving the problem of implementing Academic payroll system

Provide an analysis and comparison of your experience to develop a code with analysis-design-implementation cycle and with XP approach

The project must be done by groups of 2 students

Bonuses

1.Delivering all Homeworks 1,2,3,4 in due time gives 5 bonus points to written exam (this assumes that all Homeworks are approved) 2. In case of Late Submission of any Homework, No bonus points will be awarded for the “in-time submission of homeworks”. 3. Delivering project work before October 20 gives 5 bonus points to written exam (this assumes that the project work is approved)

ALL Bonus points are only valid for the first exam on October 18

Course literature

Object-Oriented Software Engineering: Using UML, Patterns and Java: International Edition, 3/E Bernd Bruegge, Allen H. Dutoit, ISBN-10: 0136061257, ISBN-13: 9780136061250 Publisher: Prentice Hall, Copyright: 2010, 800 pp Published: 07/29/2009 (available in the Kista Electrum book store)

Lecture notes

Additional articles in the curriculum will be added during the course

Very Tentative Lecture Plan

Date

Lecture

1 06.09.2010

Introduction and Software Lifecycles

2 13.09.2010

UML Basics

3 17.09.2010

Requirements Elicitation

4 20.09.2010

Requirements Analysis

5 24.09.2010

System Design

6 27.09.2010

Object Design (reuse)

7 01.10.2010

Object Design (Interface Design)

8 04.10.2010

Move to code, Testing, Extreme Programming and other Agile methods

9 08.10.2010

Homework/Extreme Programming and other Agile methods

10 11.10.2010

Guest lecture from Microsoft

Objectives of the Course

• Learn about Software Engineering methods:

– how to build complex software systems when the context frequently changes

• Learn methods for dealing with complexity and changes in software construction

• Be able to evaluate and choose methods for producing a high quality software system within time

• Get technical knowledge and some managerial knowledge for software construction

Introduction Content

• Introduction

• Software nature

• Definitions of Software Engineering

• Dealing with complexity

– Abstraction

– Decomposition

– Hierarchy

• Software development concepts and activities

• Software development lifecycle

Literature used

• Text book Object-Oriented Software Engineering: Using UML, Patterns and Java” International Edition, 3/E Bernd Bruegge, Allen H. Dutoit

Chapters 1, 15, 16

What is Software?

– computer programs

– associated documentation

– associated data that is needed to make the programs operatable

Software’s Nature

• Software is

– intangible – it is difficult to understand development efforts

– easily reproducible – cost is not in manufacturing but in development

– labor-intensive – hard to automate

– easy to modify

– a logical rather than physical product – it doesn’t wear out with use

– untrained people can hack something together

Adopted from Lethbridge and Laganière.

Some known software failures

Item: In the summer of 1991, telephone outages occurred in local telephone systems in California and along the Eastern seaboard. These breakdowns were all the fault of an error in signaling software. Right before the outages, DSC Communications (Plano, TX) introduced a bug when it changed three lines of code in the several-million-line signaling program. After this tiny change, nobody thought it necessary to retest the program.

Item: In 1986, two cancer patients at the East Texas Cancer Center in Tyler received fatal radiation overdoses from the Therac-25, a computer-controlled radiation-therapy machine. There were several errors, among them the failure of the programmer to detect a race condition (i.e., miscoordination between concurrent tasks).

Item: A New Jersey inmate escaped from computer-monitored house arrest in the spring of 1992. He simply removed the rivets holding his electronic anklet together and went off to commit a murder. A computer detected the tampering. However, when it called a second computer to report the incident, the first computer received a busy signal and never called back.

From http://www.byte.com/art/9512/sec6/art1.htm

Example: Space Shuttle Software

• Cost: $10 Billion, millions of dollars more than planned

• Time: 3 years late

• Quality: First launch of Columbia was cancelled because of a synchronization problem with the Shuttle's 5 onboard computers.

– Error was traced back to a change made 2 years earlier when a programmer changed a delay factor in an interrupt handler from 50 to 80 milliseconds.

– The likelihood of the error was small enough, that the error caused no harm during thousands of hours of testing.

• Substantial errors still exist.

– Astronauts are supplied with a book of known software problems "Program Notes and Waivers".

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Do you know this product?

Do you know this product?

Software failures – some reasons

• Seldom occurring situations are not taken into account
• Users can actively misusing systems
• Management failures
• Unnecessary complexity
• .

.

.

Software project failures

• Terminated for non-performance of contract.

• Completed but the system is not deployed as users cannot or will not use it.

• Completed but the system does not meet the originally promised

• cost

• schedule.

• quality.

• capability.

• Completed but the system could not be evolved in a cost-effective manner

Adopted from Charette 1989

Software projects

• The Standish Group delivered “Chaos Report”

– 365 IT executives in US companies in diverse industry segments.

– 8,380 projects

• In 1994 only 16.2% of software projects were completed on-time and on-budget (for large and complex systems it is 9%)

– average time overrun = 222%.

– average cost overrun = 189%

– 61% of originally specified features included

• In 2003 , it is 34% of projects completed on-time and on-budget

Project completion

53%

Project completion 53% 16% 31% On time, on budget, with all of the specified features and
Project completion 53% 16% 31% On time, on budget, with all of the specified features and
16%
16%

31%

On time, on budget, with all of the specified features and functionsCancelled before they were completed delivered and operational but over- budget, over-schedule or with fewer

Cancelled before they were completedon budget, with all of the specified features and functions delivered and operational but over- budget,

delivered and operational but over- budget, over-schedule or with fewer features and functions thanOn time, on budget, with all of the specified features and functions Cancelled before they were

Software’s nature

• Demand for software is high and rising

• In many cases software has poor design and it getting worse

• “software crisis” in a permanent state

• We have to learn to engineer software

What is Software Engineering?

Software Engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real

machines [from Fritz Bauer in Pressman 1997, pA-1]

sound engineering principles implies:

– a specification followed by an implementation

– a demonstration that the solution does what it is supposed to do

– the adoption of sound project management practices

– the availability of a range of tools and techniques

obtain economically implies:

– productivity estimation measures

– cost estimation and measures

reliability and efficiency imply:

– performance measures

– standards

– quality

What is Software Engineering?

The IEEE describes Software Engineering as “the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software”

quantifiable implies measurement

• the discipline is not only concerned with development but also maintenance and operation

Software Engineering

• The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists.

– Grady Booch, in Object-Oriented Analysis and Design

What is Software Engineering?

• Brygge&Dutoit:

– Software Engineering is a collection of techniques, methodologies and tools that help with the production of

• a high quality software system

• with a given budget

• before a given deadline

• while change occurs.

What is Software Engineering?

• Software engineering is a modeling activity.

• Software engineering is a problem-solving activity.

• Software engineering is a knowledge acquisition activity.

• Software engineering is a rationale-driven activity.

Scientist, Engineer and Software Engineer

• (Computer) scientist

– concerns theories and methods that underlie computer and software systems

– Has (almost) no time constraints

• Engineer

– works in application specific domain

– has time constraints

• Software engineer

– woks in multiple application domain

– has time constraints

– changes can occur in requirements and technology

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Factors of Software Design

• Complexity

– The problem domain is difficult because of often we are not experts in it

– The development process is very difficult to manage

– Software is extremely flexible – easy to modify

• Changes

– each change makes next change more expensive

– the cost of implementing changes grows in time

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

How to deal with complexity?

• Abstraction

-- Ignore non-essential details - modeling

• Decomposition

-- Break problem into sub-problems

• Hierarchy

-- Simple relationship between chunks

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Abstraction/Modeling

• System Model:

– Object Model: What is the structure of the system? What are the objects and how are they related?

– Functional model: What are the functions of the system? How is data flowing through the system?

– Dynamic model: How does the system react to external events? How is the event flow in the system ?

• Task Model:

– What are the dependencies between the tasks?

– How can this be done within the time limit?

– What are the roles in the project or organization?

• Issues Model:

– What are the open and closed issues? What constraints were posed by the client? What resolutions were made?

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Abstraction/Models

Object Model Dynamic Model class class Code Functional class Model
Object Model
Dynamic Model
class
class
Code
Functional
class
Model

System Models

Forward

Engineering

Reverse

Engineering

Constraints Arguments Org Chart Issues Pro Con Proposals PERT Chart
Constraints
Arguments
Org Chart
Issues
Pro Con
Proposals
PERT Chart

Issue Model

Task Models

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Building a House (Dependency Graph)

Install Install Install Interior Interior Wallboard Plumbing Electrical Paint Interior Install Flooring Lay
Install
Install
Install
Interior
Interior
Wallboard
Plumbing
Electrical
Paint
Interior
Install
Flooring
Lay
Build
Excava
Survey
Buy
Founda
tion
ing
Material
tion
Request
START
START

The activity „Buy Material“ must Precede the activity „Lay foundation“

Install Interior Doors FINISH Outside Wall Install Roofing Install Exterior Doors Paint Exterior Install
Install
Interior
Doors
FINISH
Outside
Wall
Install
Roofing
Install
Exterior
Doors
Paint
Exterior
Install
Install
Install
Exterior
Exterior
Exterior
Siding
Plumbing
Electrical

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Gantt Chart

Activity 1 Activity 2 Activity 3 Activity 4 Activity 5 0 1 2 3 4
Activity 1
Activity 2
Activity 3
Activity 4
Activity 5
0
1
2
3
4
5
6
7

Easy to read

Time (in weeks after start)

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Gantt Chart with milestones

Project Start Activity 1 Activity 2 Activity 3 Design Review Activity 4 Activity 5 Project
Project Start
Activity 1
Activity 2
Activity 3
Design Review
Activity 4
Activity 5
Project Finish
0
1
2
3
4
5
6
7

Good for reviews.

Time (in weeks after start)

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Types of Gantt Charts

Person-Centered View

To determine people‘s load

Joe

Mary

Toby

Clara

A1

A1 A2 A3

A2

A3

A1

A3

A3

A1 A2 A3 A1 A3 A3 Time

Time

Activity-Centered View

To identify teams working together on the same tasks Joe, Toby A1 Joe A2 Clara,
To identify teams working
together on the same tasks
Joe, Toby
A1
Joe
A2
Clara, Toby, Joe
A3
Time

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Issue Model

Issue:

What is the Center of the Universe?

Resolution (1615):

The church decides proposal 1 is right

Resolution (1615): The church decides proposal 1 is right Resolution (1998): The church declares proposal 1

Resolution (1998):

The church declares proposal 1 was wrong

(1998): The church declares proposal 1 was wrong Proposal1: The earth! Proposal2: The sun ! Pro:
(1998): The church declares proposal 1 was wrong Proposal1: The earth! Proposal2: The sun ! Pro:
(1998): The church declares proposal 1 was wrong Proposal1: The earth! Proposal2: The sun ! Pro:
(1998): The church declares proposal 1 was wrong Proposal1: The earth! Proposal2: The sun ! Pro:

Proposal1:

The earth!

Proposal2:

The sun!

1 was wrong Proposal1: The earth! Proposal2: The sun ! Pro: Change will disturb the people.
1 was wrong Proposal1: The earth! Proposal2: The sun ! Pro: Change will disturb the people.
Pro: Change will disturb the people.
Pro:
Change will disturb
the people.
Pro: Aristotle says so.
Pro:
Aristotle
says so.

Pro:

Copernicus says so.

Con: Jupiter’s moons rotate around Jupiter, not around Earth.
Con:
Jupiter’s moons rotate
around Jupiter, not
around Earth.

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Decomposition

• Functional decomposition - emphasizes the ordering of operations

– The system is decomposed into functional modules

– Each module is a processing step (function) in the application domain

– Modules can be decomposed into smaller modules

• Object-oriented decomposition - emphasizes the agents that cause the operations

– The system is decomposed into classes (“objects”)

– Each class is a major abstraction in the application domain

– Classes can be decomposed into smaller classes

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Functional Decomposition

System Function Read Process Output Process Output
System
Function
Read
Process
Output
Process
Output
System Function Read Process Output Process Output Read Level 1 functions Level 2 functions Load R5
Read
Read

Level 1 functions

Level 2 functions

Process Output Read Level 1 functions Level 2 functions Load R5 Add R1, R5 Adopted from
Load R5
Load R5

Add R1, R5

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Functional decomposition

Autoshape Change Draw Change Change Change Oval Circle Draw Draw Oval
Autoshape
Change
Draw
Change
Change
Change
Oval
Circle
Draw
Draw
Oval

Rectangle

Mouse

click

Rectangle

Draw Circle
Draw
Circle

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Object decomposition

   

Shape

 
     
     
 

Circle

Rectangle

 

Oval

 
   

Draw

Draw

Draw

Change

Change

Change

Object-Oriented Decomposition

 

Eskimo

 

Size

 
  Dress()  

Dress()

  Dress()  
 
 

Smile()

Sleep()

 

*

Shoe

 

Coat

Size

Size

Color

Color

Type

Type

Wear()

Wear()

Color Color Type Type Wear() Wear() Ear Size listen() * Indian Dress() Smile() Sleep() Hair

Ear

Size

listen()

*

Type Type Wear() Wear() Ear Size listen() * Indian Dress() Smile() Sleep() Hair Mouth NrOfTeeths Size

Indian

Dress()

Smile()

Sleep()

Wear() Ear Size listen() * Indian Dress() Smile() Sleep() Hair Mouth NrOfTeeths Size Face Nose smile()

Hair

Mouth

NrOfTeeths

Size

* Indian Dress() Smile() Sleep() Hair Mouth NrOfTeeths Size Face Nose smile() close_eye() open() speak() Adopted

Face

Nose

smile()

close_eye()

open()

speak()

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Modeling Briefcase

Modeling Briefcase BriefCase Chair Capacity: Integer Weight: Integer Open() Close() Carry() SitOnIt()
Modeling Briefcase BriefCase Chair Capacity: Integer Weight: Integer Open() Close() Carry() SitOnIt()

BriefCaseChair

Capacity: Integer Weight: Integer

Open()

Close()

Carry()

SitOnIt()

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Hierarchy

• Relationships between components obtained from abstraction and decomposition

• Hierarchy is one of ways to provide simple relationships

• Part-of-hierarchy

• Is-kind-of hierarchy

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Part-of hierarchy

Computer

Part-of hierarchy Computer I/O Devices CPU Memory Cache ALU Program Counter Adopted from Bernd Bruegge &
I/O Devices CPU Memory Cache ALU Program Counter
I/O Devices
CPU
Memory
Cache
ALU
Program
Counter

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Is-a-kind-of hierarchy

Cell

Is-a-kind-of hierarchy Cell Nerve Cell Muscle Cell Blood Cell Cortical Pyramidal Smooth Red White Striate Adopted
Nerve Cell Muscle Cell Blood Cell Cortical Pyramidal Smooth Red White Striate
Nerve Cell
Muscle Cell
Blood Cell
Cortical
Pyramidal
Smooth
Red
White
Striate

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Where we are now?

• Three ways to deal with complexity:

– Abstraction

– Decomposition

– Hierarchy

• Object-oriented decomposition is a good methodology

– Unfortunately, depending on the purpose of the system, different objects can be found

• How can we do it right?

– Many different possibilities

– Our current approach: Start with a description of the functionality, then proceed to the object model

– This leads us to the software lifecycle

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Software Engineering Concepts (resources)

• Resources include time, equipment and labor

• Participants – all actors involved in the project

• Roles – set of responsibilities in the project

– associated with a set of tasks and they are assigned to participants

– participant can fill multiple roles

• Example of roles: client, user, manager, developer, technical writer

• Example of participants: traveler, train company, John, Alice, Zoe

• Example of role assignments: Alice – manager, John – technical writer and analyst

• Other resources: Tariff Database

Software Engineering Concepts (Work Products)

• System – collection of interconnected parts

– TicketDistributor system

• Model - abstraction of a system

– Schematics of electrical wiring, object model

• Document

– description

• Work product can be

– internal - for project consumption

• test manual

• workplan

– deliverable – delivers to the client

• specification

• operation manual

Software Engineering Concepts (activities and tasks)

• Task – atomic unit of work to be managed

– consumes Resources

– produces Work Products

– depends on other tasks

– F/E develop “Out of Change” test case

• Activity – set of tasks performed for achieving the project’s goals

– F/E requirements elicitation

• Work on the project is broken into tasks and assigned to resources

Software Engineering Concepts’ Hierarchy

Project

Software Engineering Concepts’ Hierarchy Project * Activity   is produced by * consumes WorkProduct

*

Activity

Engineering Concepts’ Hierarchy Project * Activity   is produced by * consumes WorkProduct *
 

is produced by

*

consumes

WorkProduct

*

Task

*

Resources

consumes WorkProduct * Task * Resources System Participant Model Time Document Equipment Bernd
consumes WorkProduct * Task * Resources System Participant Model Time Document Equipment Bernd
System Participant Model Time Document Equipment
System
Participant
Model
Time
Document
Equipment

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java - adopted from OMG

Possible SE activities - Simplified view

Requirements Analysis

System Design

Object Design

Implementation

Problem

Domain

What is the problem?

What is the solution?

What is the solution in the context of an existing hardware system?

How is the solution constructed?

Implementation

Domain

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Software Engineering Development Activities

Analysis – concentrates on system requirements – definitions of a system from users’ point of view

Requirements elicitation – determining functionality user needs and a way of its delivering

Requirements analysis – formalizing determined requirements and ensuring their completeness and consistency

Design – constructing the system

System design – defining a system architecture in terms of design goals and a subsystem decomposition

Object design – modeling and construction activities related to the solution domain

Implementation – translation of the solution domain model into code

Testing – the goal is to discover faults in the system to be repaired before the system delivery

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Activities and Models

Requirements

Elicitation

Analysis

System

Object

Implemen-

Design

Design

tation

Testing

Object Implemen- Design Design tation Testing Implemented By Verified By ? Expressed in Terms Of

Implemented

By

Verified By ?
Verified
By
?
Design tation Testing Implemented By Verified By ? Expressed in Terms Of Structured By Application Domain
Design tation Testing Implemented By Verified By ? Expressed in Terms Of Structured By Application Domain

Expressed in

Terms Of

Structured By

By Verified By ? Expressed in Terms Of Structured By Application Domain Objects Realized By Solution
By Verified By ? Expressed in Terms Of Structured By Application Domain Objects Realized By Solution

Application

Domain

Objects

Realized By

Of Structured By Application Domain Objects Realized By Solution Domain Objects class class class Source Code

Solution

Domain

Objects

Domain Objects Realized By Solution Domain Objects class class class Source Code class ? Test Cases

class

class

class

Source

Code

class

?

Test

Cases

Use Case

Model

Subsystems

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Software Life-Cycle

• Which activities should be selected for the software project?

• What are the dependencies between activities?

– Does system design depend on analysis? Does analysis depend on design?

• How should the activities be schedule?

– Should analysis precede design?

– Can analysis and design be done in parallel?

– Should they be done iteratively?

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Software Life-cycle

• Life-cycle differs between projects

• Different experience and skills

• Different application domains

• Environment changes

• Project size

Software Life-Cycle

Conception Pre-
Conception
Pre-

Development

Adulthood Childhood Childhood Post- Development Development
Adulthood
Childhood Childhood
Post-
Development Development
Retirement
Retirement

Development

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

IEEE 1074: Standard for Developing Software Lifecycle Processes

• Describes a set of activities and processes that are mandatory for development and maintenance of software

• Establishes a common framework for developing lifecycle models

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

IEEE 1074: Standard for Developing Software Lifecycle Processes

• Process Group - consists of Set of Processes

– Design process is a part of Development group

• Process - consists of Activities. Design process may consist of:

– Perform Architectural Design

– Design Database (If Applicable)

– Design Interfaces

– Select or Develop Algorithms (If Applicable)

– Perform Detailed Design (= Object Design)

• Activity - consists of subactivities and tasks. Design Database activity may consist of:

Review Relational Databases

Review Object-Oriented Databases

Make a Purchase recommendation

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

IEEE 1074: Standard for Developing Software Lifecycle Processes

• Process Group: Consists of Set of Processes

• Process: Consists of Activities

• Activity: Consists of sub activities and tasks

Development Development

of sub activities and tasks Development Development Process Process Group Group Process Process Design Design
of sub activities and tasks Development Development Process Process Group Group Process Process Design Design
Process Process Group Group
Process Process
Group Group
tasks Development Development Process Process Group Group Process Process Design Design Activity Activity Design

Process Process

Development Process Process Group Group Process Process Design Design Activity Activity Design Design Database
Development Process Process Group Group Process Process Design Design Activity Activity Design Design Database

Design Design

Process Process Group Group Process Process Design Design Activity Activity Design Design Database Database Task
Process Process Group Group Process Process Design Design Activity Activity Design Design Database Database Task
Activity Activity
Activity Activity

Design Design

Database Database

Design Activity Activity Design Design Database Database Task Task Make Make a a Purchase Purchase
Design Activity Activity Design Design Database Database Task Task Make Make a a Purchase Purchase

Task Task

Activity Design Design Database Database Task Task Make Make a a Purchase Purchase Recommendation

Make Make a a Purchase Purchase Recommendation Recommendation

a a Purchase Purchase Recommendation Recommendation Adopted from Bernd Bruegge & Allen H. Dutoit
a a Purchase Purchase Recommendation Recommendation Adopted from Bernd Bruegge & Allen H. Dutoit
a a Purchase Purchase Recommendation Recommendation Adopted from Bernd Bruegge & Allen H. Dutoit

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

IEEE 1074: Standard for Developing Software Lifecycle Processes Life Life Cycle Cycle Process Group Modeling
IEEE 1074: Standard for Developing
Software Lifecycle Processes
Life Life Cycle Cycle
Process Group
Modeling Modeling
IEEE IEEE 1074 1074
>
Selection of Life Cycle model
Cross-
Pre-
Develop-
Post-
Cross-
Project Project
Pre-
Develop-
Post-
Development Development
Management Management
Development Development
ment ment
Development Development
(Integral (Integral Processes) Processes)
> Project Initiation
> Requirements
> Installation
> V & V
> Concept
>Project Monitoring
&Control
Analysis
> Operation &
> Configuration
Exploration
> Design
Support
Management
> System
> Software Quality
Management
> Implemen-
> Maintenance
> Documen-
Allocation
tation
> Retirement
tation
> Training

Processes

Adopted Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Project Management Process Group

Project Project Management Management
Project Project
Management Management
Project Project Monitoring Monitoring & & Control Control
Project Project
Monitoring Monitoring
& & Control Control
Project Monitoring Monitoring & & Control Control Project Project Initiation Initiation Software Software
Project Monitoring Monitoring & & Control Control Project Project Initiation Initiation Software Software

Project Project

Initiation Initiation

Software Software

Quality Quality

Management

Management

Map Activities to Software Life Cycle Model Allocate Project Resources Establish Project Environment Plan Project Management

Analyze Risks Perform Contingency Planning Manage the Project Retain Records Implement Problem Reporting Model

Plan Software Quality Mesurement Define Metrics Manage Software Quality Identify Quality Improvement Needs

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

IEEE 1074 standard.

Development processes Management processes Integral processes Concept Exploration Process System Allocation
Development processes
Management processes
Integral processes
Concept
Exploration
Process
System
Allocation
Process
Project
Configuration
Requirements
Initiation
Management
Process
Process
Process
Design
Process
Project
Documentation
Implementation
Monitoring
Development
Process
&Ctrl Process
Process
Installation
Process
Operation
S/W Quality
Training
& Support
Management
Process
Process
Process
Maintenance
Verification
Process
& Validation
Process
Retirement
Process

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Capability Maturity Model (CMM)

Level 1: Initial

– Ad hoc activities applied

– Success depends on skills of key individuals

– System is black box for users

– No interaction with user during the project

Level 2: Repeatable

– Each project has well-defined software life cycle

– Models differ from project to project

– Previous experience in similar projects allows predictability success

– Interaction with user in defined points

Level 3: Defined

– Documented software life cycle model is used for all activities

– Customized version of the model is produced for each project

– User knows standard model and the model selected for the project

Level 4: Managed

– Metrics for activities and deliverables defined

– Collecting data during project duration

– The software life cycle model can be analyzed

– User informed about the risks before the project and knows the measures

Level 5: Optimized

– The measurement data are used as a feedback to improve the software life cycle over lifetime of the organization

– The user, mangers and developers communicate and work together during the whole project

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

What do we want?

Requirements

Design Implementation
Design
Implementation
What do we want? Requirements Design Implementation Testing Software Adopted from Bernd Bruegge & Allen H.
Testing Software

Testing

Testing Software
Testing Software
Testing Software
Testing Software
Testing Software
Testing Software
Testing Software
Testing Software
Testing Software
Testing Software
Testing Software
Testing Software
Software

Software

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Waterfall Model

Concept Exploration Process System Allocation Process Requirements Process Design Process Implementation
Concept
Exploration
Process
System
Allocation
Process
Requirements
Process
Design
Process
Implementation
Process
Verification
& Validation
Process
Installation
Process
Operation &
Support Process

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Waterfall model

• Managers like waterfall models:

– Clear milestones

– No need to look back (linear system), one activity at a time

– Easy to check progress : 90% coded, 20% tested

• In practice, software development is not sequential

– The development stages overlap

• Different stakeholders need different abstractions

• System development is a nonlinear activity

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Waterfall model with prototyping

Requirements Engineering Requirements Analysis System Design Object Design Implementation Process Prototyping
Requirements
Engineering
Requirements
Analysis
System
Design
Object
Design
Implementation
Process
Prototyping
Verification
& Validation
Process
Installation
Process
Operation &
Support Process
V- model Acceptance Requirements Engineering System Requirements Testing Analysis Integration System Design
V- model
Acceptance
Requirements
Engineering
System
Requirements
Testing
Analysis
Integration
System Design
Testing
Unit
Object Design
Testing
Implemen-
tation
Unit
Testing
Integration
Testing
System
Testing
Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002

V-Model

System Is validated by Requirements Operation Analysis precedes Software Client Requirements Acceptance
System
Is validated by
Requirements
Operation
Analysis
precedes
Software
Client
Requirements
Acceptance
Elicitation
System
Requirements
Integration
Analysis
& Test
Component
Preliminary
Integration
Design
& Test
Detailed
Unit
Design
Test
Implementation

Copyright 2002 Bernd Brügge Software Engineering II, Lecture 3: Scheduling SS 2002

Features and functionality

Incremental model

analysis

analysis

analysis
analysis
analysis

design

implementation

deployment

analysis design
analysis
design

implementation

deployment

design
design

implementation

deployment

implementation deployment analysis design implementation deployment design implementation deployment Time

Time

Iterative models

• Software development is iterative

– During design problems with requirements are identified

– During coding, design and requirement problems are found

– During testing, coding, design & requirement errors are found => Spiral Model

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Spiral model

• The spiral model proposed by Boehm is an iterative model with the following activities

– Determine objectives and constraints

– Evaluate Alternatives

– Identify risks

– Resolve risks by assigning priorities to risks

– Develop a series of prototypes for the identified risks starting with the highest risk.

– Use a waterfall model for each prototype development (“cycle”)

– If a risk has successfully been resolved, evaluate the results of the “cycle” and plan the next round

– If a certain risk cannot be resolved, terminate the project immediately

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Spiral model

Rounds/cycles

• Concept of Operation,

• Software Requirements,

• Software Product Design,

• Detailed Design,

• Code,

• Unit Test,

• Integration and Test,

• Acceptance

For each cycle go through these activities

– Quadrant IV: Define objectives, alternatives, constraints

– Quadrant I: Evaluate alternative, identify and resolve risks

– Quadrant II: Develop, verify prototype

– Quadrant III: Plan next “cycle”

IV

Determine objectives

IV

Specify constraints

IV

Generate alternatives

I

Identify risks

I

Resolve risks

II Develop and verify prototype

III Plan

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Spiral model

Project

cost

Risk analysis Prototyping
Risk analysis
Prototyping

Define Objectives

“continue,

not-continue”

decision

Project

Customer evaluation and next round planning

progress

Spiral Model

Determine objectives, alternatives, & constraints Risk analysis Risk analysis Risk analysis P1 Prototype3
Determine objectives,
alternatives, & constraints
Risk
analysis
Risk
analysis
Risk
analysis
P1
Prototype3
Prototype2
Prototype1
Requirements
Concept of
plan
operation
Software
System
Requirements
Product
Detailed
Design
Design
Development
Requirements
plan
validation
P2
Code
Integration
Design
Unit Test
plan
validation
Plan next phase
Requirements and
Life cycle Planning
Integration & Test
Acceptance
Test

Evaluate alternatives, identify & resolve risks

Risk Analysis activity

Start Project

Start New Round

Develop & verify next level product

Development system product Activity

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java Adopted from Boem

Limitations of Waterfall and Spiral Models

• Neither of these model deals well with frequent change

– The Waterfall model assume that once you are done with a phase, all issues covered in that phase are closed and cannot be reopened

– The Spiral model can deal with change between phases, but once inside a phase, no change is allowed

• What do you do if change is happening more frequently? (“The only constant is the change”)

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Unified Software Development Process (UP)

• Repeats over a series of cycles

Birth Death
Birth
Death

Cycles conducted with a release

• Each cycle consists of four phases which are subdivided into iterations

Inception

Elaboration

Construction

Transition

Iteration

Iteration

             

Iteration

Iteration

No1

No2

 

No n-1

No n

Unified process

• Inception – establishes a business case for the system

• Elaboration – most of the product cases are specified in details, architecture is designed

• Construction – the product is built. The architectural baseline becomes a full-pledged system

• Transition – period when product moves to beta release

Unified Software Development Process (UP)

• UP organizes projects in two-dimensional terms

• The horizontal dimension represents the successive phases of each project iteration:

– inception,

– elaboration,

– construction, and

– transition.

• The vertical dimension represents software development disciplines and supporting activities of configuration and change management, project management, and environment.

• Cross-functional

Workflows

– Management – planning aspects

– Environment – automation of the process itself

– Assessment – assesses processes and products needed for reviews

– Deployment – transition of the system

• Engineering

– Requirements

– Design

– Implementation

– Testing

Unified Software Development Process

An iteration in the elaboration phase

Inception Elaboration Construction Transition Iter.#1 Iter.#2 Iter.# Iter.# Iter.# Iter.# Iter.# Iter.#n-1
Inception
Elaboration
Construction Transition
Iter.#1
Iter.#2
Iter.#
Iter.#
Iter.#
Iter.#
Iter.#
Iter.#n-1
Iter.#n
Management Workflow
Environment Workflow
Requirements Workflow
Design Workflow
Implementation Workflow
Assessment Workflow
Deployment Workflow

Time

From Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java adopted from Jacobson

UP vs. Waterfall

Risk

seriousness

Waterfall Inception Waterfall integration and test period Elaboration Construction Iter.#1 Iter.#2 Iter.# Iter.#
Waterfall
Inception
Waterfall integration and
test period
Elaboration
Construction
Iter.#1 Iter.#2
Iter.#
Iter.#
Iter.#
Iter.#
Iter.#
Transition
Iter.#n-1 Iter.#n
time

Formal software development models

deductive methods,

which uses automatic deduction of a proof of solvability of a problem and derives a program from the proof

transformational methods,

where a program is derived stepwise from a specification by means of transformations

inductive methods,

where a program is built on the basis of input- output pairs or examples of computations

Inductive synthesis - Basic notions (Program specification)

• The expression "programming by examples" is taken to mean the act of specifying a program by means of examples of the program behavior

• Examples consisting of expressions representing an input and output (A B C) C

(A B) B,

(A B C) B,

(A B C D) B

Program specification

• A single example indicates a specific transformation or computation that must be duplicated by any program defined by the examples

• For any finite set of examples there are an infinite number of programs that behave like the examples.

• Program satisfies or is defined by a set of examples if it produces the examples output when applied to the examples input for all examples in the specifying set.

General methods (search)

• A fundamental method of inductive inference is to search in some systematic way through the space of possible programs (rules)

• Possible program should be agree with all examples

General methods (search)

• Basic advantage of search is that it is a general method and does not depend much on domain-specific knowledge

• Basic disadvantage of search is that in a general case it can be very inefficient

Deductive Synthesis

It is based on the observation that constructive proofs are equivalent to programs because each step of a constructive proof can be interpreted as a step of computation.

The way from a problem to program

Problem in source form

Problem represented in a formal theory

Proof of solvability of the problem

Program

Deductive synthesis problem

• suppose that program to be derived takes an input x and produces an output y

• suppose that specification of the program states that a precondition P(x) should be true of the input and that a post-condition Q(x,y) should be true of the output

• then the theorem to be proven is x y[P(x) Q(x,y)]

Structural synthesis of programs

The idea of Structural Synthesis of Programs (SSP) is that a proof of solvability of a problem can be built and that the overall structure of a problem can be derived from the proof, knowing very little about properties of the functions used in the program

Logical language of SSP (LL-language)

• Propositional variables (begin with capital letters):

A, B, C, D, Ai, A i

• Unconditional computability statements:

A 1 &

& A k B

we also use A as an abbreviation for A 1 &

& A k

• Conditional computability statements

(A 1 B 1

we also use ( A B) as an abbreviation for

) &

& (A n B n

) (C D)

( A 1

B 1 ) &

& (A n

B n

).

Informal meaning

A 1 &

• Logical meaning "A 1 ,

&A k B has two meanings

A k implies B",

, A k , B - propositional variables

where A 1 ,

,

• Computational meaning ”B is computable

from A 1 ,

A

A k "

, A k , B - computational objects

1 ,

,

Computational meaning of the LL formulae

• Propositional variables of LL correspond to object variables from the source problem description language (specification language).

• An unconditional computability statement A B expresses a computability of the value of the object variable b corresponding to B from values

of a 1

a k corresponding to A.

• A conditional computability statement, e.g. (A B) (C D) expresses computability of the object variable d from c depending on other computations, here depending on the computation of the object variable b from a.

Structural synthesis rules (SSR)

ΣΣΣΣ |– A V

Γ |– A

ΣΣΣΣ , Γ

|– V

(-)

where Γ |– A is a set of sequents for all A in A

Γ, A |– B

(+)

Γ |– A B

ΣΣΣΣ |– (A B) (CV);

Γ, A |– B;

|– C

ΣΣΣΣ , Γ , |– V

(--)

where Γ, A |– B is a set of sequents for all A B in

(A B), and |– C is a set of sequents for all C in

C.

SSR1 inference rules

Σ |– A f V ;

Γ |– A(a)

Σ, Γ |– V(f(a))

Γ, A |– B(b)

(+)

Γ |–

A λ a.b

B

(-)

Σ|–(Ag B)(C F V); Γ, A|–B(b); |–C(c)

Σ, Γ ,|– V(F(λ a.b, c))

(- -)

Example. Modeling logical circuits

Class inverter inverter: (in,out: bool; finv: in out (finv)) Corresponding set of formulae INVERTER.IN finv INVERTER.OUT, INVERTER.IN & INVERTER.OUT constr(2) INVERTER, INVERTER select1 INVERTER.IN, INVERTER select2 INVERTER.OUT

Example. Modeling logical circuits

• Class and and:(in1, in2, out:bool; fand:in1, in2 out (fand)) Corresponding set of formulae AND.IN1 & AND.IN2 fand AND.OUT, AND.IN1 & AND.IN2 & AND.OUT constr3 AND, AND select1 AND.IN1, AND select2 AND.IN2, AND select3 AND.OUT

Example. Modeling logical circuits

• Class nand nand: (in1,in2,out: bool; a: and in1 = in1, in2 = in2; i: inverter in = a.out, out=out; fnand: in1,in2 out); Corresponding set of formulae

IN1 eq1 A.IN1, A.IN1 eq2 IN1, IN2 eq3 A.IN2, A.IN2 eq4 IN2, I.IN eq5 A.OUT, A.OUT eq6 I.IN, I.OUT eq7 OUT, OUT eq8 I.OUT, A.IN1 & A.IN2 a.fand A.OUT, I.IN i.finv I.OUT, A select1 A.IN1, A select2 A.IN2, A select3 A.OUT, IN1 & IN2 & OUT constr3 A, I.IN & I.OUT constr2 I, I select1 I.IN, I select2 I.OUT, IN1 & IN2 OUT

Example. Modeling logical circuits (inference)

IN1

eq1

A.IN1

IN2

eq3

A.IN2

A.OUT

I.IN

I.OUT i.inv

OUT

a.fand

eq6

i.inv

eq7

Extracted program

fand:out=eq7(i.finv(eq6(a.fand(eq1(in1), eq3(in2))))

or

fand: λin1 in2. (i.finv(a.fand(in1, in2)))

Example - Logical circuits (new)

& X1 ¬ 1 X3 ¬ & X2 ¬ X4 &
&
X1
¬
1
X3
¬
&
X2
¬
X4
&

Class SCHEMA var X1, X2, X3, X4: any; i1: Inverter in = X1; i2: Inverter in = X2; i3: Inverter in = X3;

a1: NAND in1 = t1.Q1, in2 = i1.out; a2: NAND in1 = i3.out, in2 = a3.out; a3: AND in1 = X4, in2 = t1.Q2; t1: D_latch S=1,D=i2.out, C=a2.out,R=a1.out; alias Y = t1.result; rel problem: X1, X2, X3, X4 -> Y {spec};

Problem Solving in the SSP Systems (Geometry)

s2 s1
s2 s1

s2

s1

Figure var area:numeric;

s1:SQUARE;

s2:SQUARE side = s1.diagonal;

Set of solvable problems:

s1.side s1, s2;

s1.diagonal s2; s1.side area; s2.side area; .

s2.side s1, s2;

.

.

Transformational model

Formal Development Process

Formal Specification Transform 1 Code
Formal
Specification
Transform 1
Code

System Requirements (maybe informal and incomplete)

System

Adopted fromPfleger&Atlee

Deductive and Transformational Synthesis

• Both of them are based on deduction, however, they use different deduction methods.

• Synthesis is usually based on inference, whereas transformation is usually based on replacement.

Inference means the axioms and rules supplied to the program derivation system are expressed as implications, and the logical operations of the system derive either necessary conclusions or premises of sufficient antecedents of goals.

Replacement means that the axioms supplied to the system are expressed as equations or rewrite rules, and the logical operations replace expressions by other equivalent expressions.

Correctness of transformations

• Let SP0 be a specification of the requirements which the software system is expected to fulfill, expressed in some formal specification language SL.

• The ultimate objective is a program P written in some programming language PL which satisfies the requirements in SP0.

• The main idea is to develop P from SP0 via series of small refinement steps

SP0 SP1

P

• If each individual refinement step (SP0 SP1, SP1

SP2,

)

can be proved to be correct then the

resulting program P is guaranteed to be correct.

Correctness of transformations

The notions of the "correctness of transformations" have to be based on suitable relations between programs. Given such a relation ϕ , the transition from a program P to another program P' then is said to be correct iff P ϕ P' holds.

• Some relations which are reasonable in connection with program transformations:

– P and P' have to be "equivalent"

– Weakening condition for “equivalence”: the equivalence of P and P' is only required if P is defined

– For nondeterministic programs, it may suffice that P' is included in P, - that the possible results of P' form a subset of possible results of P.

Correctness of transformations

Relation ϕ has to fulfill the following requirements:

• it has to be reflexive, since the identity should be a valid transformation;

• it has to be transitive in order to allow the successive application of several transformations

• if there is the local application of transformation to a (small) part Q of a program P, then the validity of Q ϕ Q' only implies the validity of P ϕ P', if the relation is monotonic for the constructs of the language (where P' = P[Q'/Q]).

Correctness of transformations

The formalization of relations has to refer to the actual semantic definition of the programming language under consideration (for example):

• In denotational semantics the meaning of program is specified with help of a function M mapping programs to semantic object. Two programs P1 and P2 then can be defined to be equivalent iff M(P1) = M(P2).

• In operational semantics two programs may be regarded equivalent iff they lead to the same sequences of "elementary" actions.

Model-driven architecture (MDA)

• a software design approach for the development of software systems.

• provides a set of guidelines for the structuring of specifications, which are expressed as models.

• a kind of domain engineering, and supports model-driven engineering of software systems.

• launched by the Object Management Group (OMG) in 2001

Adopted from Alan Brown

The principles of MDA (from OMG)

• Models expressed in a well-defined notation are a cornerstone to understanding systems for enterprise-scale solutions.

• The building of systems can be organized around a set of models by imposing a series of transformations between models, organized into an architectural framework of layers and transformations.

• A formal underpinning for describing models in a set of metamodels facilitates meaningful integration and transformation among models, and is the basis for automation through tools.

• Acceptance and broad adoption of this model-based approach requires industry standards to provide openness to consumers, and foster competition among vendors.

Model-Driven Architecture (MDA)

Platform Independent Model (PIM)

Platform Independent Model (PIM) Transformations/ Mappings Platform Specific Model (PSM)
Platform Independent Model (PIM) Transformations/ Mappings Platform Specific Model (PSM)

Transformations/

Mappings

Platform Specific Model (PSM)

Transformations/ Mappings Platform Specific Model (PSM) PIM Transformation Techniques PSM Transformation Techniques
Transformations/ Mappings Platform Specific Model (PSM) PIM Transformation Techniques PSM Transformation Techniques

PIM Transformation Techniques

PSM Transformation Techniques

Metamodel tranformation

Metamodel tranformation From MDA Guide Version 1.0.1

Model tranformation

Model tranformation From MDA Guide Version 1.0.1

Model Driven Development

• Developer develops model(s) based on certain metamodel(s).

• Using code generation templates, the model is transformed to executable code.

• Optionally, the generated code is merged with manually written code.

• One or more model-to-model transformation steps may precede code generation.

written code. • One or more model-to-model transformation steps may precede code generation. Adopted from Alan

Adopted from Alan Brown

Model Driven Architecture

Customer requirements Mostly text Analysis Platform Independent Model (PIM) Design Platform Specific Model (PSM)
Customer requirements
Mostly text
Analysis
Platform
Independent
Model (PIM)
Design
Platform
Specific
Model (PSM)
PSM
bridge
Platform
Specific
Model (PSM)
Coding
Code
Code
Code
bridge
Testing
Deployment

How much Planning?

• Two styles of navigation [Gladwin 1964]

– European navigation

– “Polynesian navigation”

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

“European Navigation”

Planned Route Lima (Current Location) Auckland (Desired Location) Actual Route Event: Course deviation. Action:
Planned Route
Lima
(Current Location)
Auckland
(Desired Location)
Actual Route
Event: Course deviation.
Action: Course correction

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Polynesian Navigation

“We need a new place for living. Let’s go to Auckland” Lima (Current location) Event:
“We need a new place
for living.
Let’s go to Auckland”
Lima
(Current location)
Event: “Birds seen”
Action: “Follow the birds”
Tahiti
(Empty island, great
place for Living)

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Auckland Project Plan (European Navigation)

• Project Goal: Auckland

• Desired Outcome: Auckland is found

• Team: Captain and 50 sailors

• Organization: Flat hierarchy

• Tools: Compass, speed meter, map

• Methods: Determine planned course, write planned course before departure. Example: Start Lima. Sail West, keep the compass constantly at 97 degrees, stay at latitude 20 degrees

• Work breakdown structure

• Task T1 (Check direction): Determine current direction of ship

• Task T2 (Compute deviation): Determine deviation from desired course

• Task T3 (Course Correction): Bring ship back on course

• Process:

– T1 and T2 are executed hourly. If there is a deviation, T3 is executed to bring the ship back on the planned course.

• Schedule: With good wind 50 days, if doldrums are encountered, 85 days.

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Auckland Project Plan (Polynesian Navigation)

• Project Goal: Auckland

• Desired Outcome: A new place for living is found

• Team: Captain and 50 sailors

• Organization: Flat hierarchy

• Tools: Use stars for navigation, measure water temperature with hand

• Methods: Set up a set of event-action rules. When an event occurs, determine the action to be executed in the given context.

• Work breakdown structure

– Task T1 (Determine direction): Set direction of ship to a certain course

– Task T2 (Check Clouds): Look for non-moving clouds in the distance

– Task T3 (Check Birds): Look for birds and determine their direction

– Task T4 (Compute course): Determine new course for ship

– Task T5 (Change course): Change direction to follow new course

• Process:

– Start with T1. Tasks T2 and T3 are executed regularly. The result (cloud detected, birds detected, nothing happened) is interpreted in the current context. If the interpretation makes a new course more promising, execute task T4 and T5.

• Schedule: None

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Situated action

• Situated action [Suchman 1990]

– Selection of action depends on the type of event, the situation and the skill of the developer. Also called context-dependent action.

• Examples of navigation events: “Course deviation”, “Birds seen”, “Clouds seen”.

• European Navigation is context independent:

– Event: “Course deviation in the morning”

• Action: “Course correction towards planned route”

– Event: “Course deviation in the evening”

• Action: “Course correction towards planned route”

• Polynesian Navigation is context dependent:

– Event: “Birds seen”, Context: Morning

• Action: “Sail opposite to the direction the birds are flying”

– Event: “Birds seen”, Context: Evening

• Action: “Sail in the direction the birds are flying

Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Agile software development

Key points of agility in software production:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Adopted from: http://agilemanifesto.org/

Agile Development

Agile Development Test-driven development Refactoring Acceptance tests User stories Continuous integration Adopted from

Test-driven

development

Refactoring

Agile Development Test-driven development Refactoring Acceptance tests User stories Continuous integration Adopted from
Agile Development Test-driven development Refactoring Acceptance tests User stories Continuous integration Adopted from

Acceptance

tests

Test-driven development Refactoring Acceptance tests User stories Continuous integration Adopted from XPExplored,

User

stories

Continuous

integration

Test-driven development Refactoring Acceptance tests User stories Continuous integration Adopted from XPExplored, by Wake

Adopted from XPExplored, by Wake

Summary

• Software engineering is a modeling, problem-solving activity, knowledge acquisition activity and rationale-driven activity.

• Dealing with complexity:

• Abstraction

• Decomposition

• Hierarchy

• Software Engineering activities

– Analysis

Requirements elicitation

Requirements analysis

– Design

System design

Object design

– Implementation

– Testing

• Software Development Life Cycle

– Waterfall

– Incremental

– Spiral/UP

– Formal methods

– Agile methods

• UML

Next lecture

Chapter 2 in the text-book.