10
COMP 354 Software Engineering I Section BB Summer 2009 Dr Greg Butler http://users.encs.concordia.ca/~gregb/home/comp354- summer2009.html

COMP 354 Software Engineering I

  • Upload
    barb

  • View
    35

  • Download
    2

Embed Size (px)

DESCRIPTION

Section BB Summer 2009 Dr Greg Butler http://users.encs.concordia.ca/~gregb/home/comp354-summer2009.html. COMP 354 Software Engineering I. Principles of Software Engineering Rigour and Formality Separation of Concerns Modularity Abstraction Anticipation of Change - PowerPoint PPT Presentation

Citation preview

Page 1: COMP 354 Software Engineering I

COMP 354Software Engineering I

Section BB Summer 2009

Dr Greg Butlerhttp://users.encs.concordia.ca/~gregb/home/comp354-summer2009.html

Page 2: COMP 354 Software Engineering I

Principles of Software Engineering

Rigour and Formality

Separation of Concerns

Modularity

Abstraction

Anticipation of Change

Generality

Incrementality

Page 3: COMP 354 Software Engineering I

Rigour and Formality

rigour is achieved by conforming to given constraints

eg using a given format for the requirements document

documenting input and output of each procedure/function

limits on number and size of modules

following company standards for the development process

rigour is a necessary complement to creativity in SE

it provides shape, direction, precision, & the ability to compare and measure

there are many levels of rigour

formality is highest degree of rigour

requires the process to be driven and evaluated by mathematical laws

Page 4: COMP 354 Software Engineering I

Separation of ConcernsSeparation of Concerns means treating individual aspects of a problem

separately --- the aim: master complexity

Separation in time

eg do requirements analysis before design

creative design in the morning, meetings in afternoon

do necessary learning and study during the week,

explore personal interests on weekends

Separation by qualities

eg deal with correctness, then deal with efficiency

Separation by views

eg data flow through a system, control/decision making within system

concurrency and synchronization, timing restrictions of a real time system

Each view highlights different concerns

Separation into parts

eg decompose system into modules, treat module internals separately

Page 5: COMP 354 Software Engineering I

ModularityModularity is when a productproduct or processprocess is composed of components/modules

+ greatly aids separation of concerns

better understandability

easier to change

modules reusable

+ high cohesion within a module when all its elements are strongly related

ie there is a very good reason why they are together

+ low coupling between modules

coupling measures the interdependence between modules

eg module A and module B share a variable x --- high coupling

Page 6: COMP 354 Software Engineering I

AbstractionAbstraction is the separation of important aspects from

unimportant aspects

A model is an abstraction

it ignores certain details

it concentrates on relevant facts

What is important/relevant varies

depending on the use made of the model

Page 7: COMP 354 Software Engineering I

Anticipation of Change

Change will occur!

Requires special effort to prepare for change/evolution

of software

documentation, modularization

configuration management

of processes

document the process

modularize the process

of personnel

documentation

training

Page 8: COMP 354 Software Engineering I

Generality

more general = able to handle more cases

use of general purpose tools, eg awk

more general program may be simpler and reusable

fewer special cases in specification

able to handle a broader range of inputs/uses

Page 9: COMP 354 Software Engineering I

Incrementalityincrement = a small step/change

incremental prototyping

identify a useful, but small, subset of the problem and implement it

build a sequence of prototypes by adding features one at a time

finally have a complete system

advantages:

early delivery of a (sub)system

early feedback from users

later (more complicated) features may not be necessary

more time to think about complicated features

separation of concerns

Page 10: COMP 354 Software Engineering I

Remember what causes problems in SE

Requirements

Architecture

Change

Complexity