Software EngineeringSoftware Engineering

Introduction (The Process)

ObjectivesObjectives

To define software engineering

To introduce a range of software engineering process models

To recap the properties and benefits of an Object Orientated approach

Software Engineering DefinedSoftware Engineering Defined

Def: The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines

Def: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software

Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available

Software EngineeringSoftware Engineering

a “quality” focusa “quality” focus

process modelprocess model

methodsmethods

toolstools

A Layered TechnologyA Layered Technology

Focus: the underlying philosophy Process: high level framework Methods: technical tasks for building software Tools: automated or semi-automated support (CASE)

Remember:Remember:

High quality = project timelinessHigh quality = project timeliness

Why?Why?

Less rework!Less rework!

The Primary Goal: High QualityThe Primary Goal: High Quality

Process: Generic PhasesProcess: Generic Phases

1. Definition (“what”): Establish what the requirements of the system are

Use system engineering, project planning, requirements analysis

2. Development (“how”): Establish how the system is to be realized – design and build

Use software design, code generation, testing

3. Support: Handle changes as the software environment evolves

Must handle four types of changes: correction, adaptation, enhancement, prevention

4. This process is complemented by a number of umbrella activities

Umbrella ActivitiesUmbrella Activities

Software project management Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management

The Process Model: AdaptabilityThe Process Model: Adaptability

the framework activities of a process model will always be applied on every project

BUT the tasks (and degree of rigor) for each activity will

vary based on: the type of project (an “entry point” to the model) characteristics of the project common sense judgment concurrence of the project team

The Fractal ModelThe Fractal Model

All stages of a software process coexist simultaneously at some level of detail

Practical processes attempt to bring order to this chaos

statusquo

problemdefinition

technicaldevelopment

solutionintegration

statusquo

The Linear (Waterfall) ModelThe Linear (Waterfall) Model

Adapted from conventional engineering cycle Oldest and most widely used (+) Works if requirements are well understood; (-) doesn’t handle

iteration well, needs up front requirements, customers must be patience

analysis design code test

System/informationengineering

The Prototyping ModelThe Prototyping Model

Early versions of the software are for demonstration and refinement purposes. They are meant to be discarded.

(+) users get a feel for the system, developers learn how to build the real thing; (-) customer may imagine that the prototype is final, initial

quick fix choices may be carried over to later development

listento

customerbuild/revisemock-up

customertest-drivesmock-up

The RAD ModelThe RAD Model

Rapid Application Development (RAD) uses component-based (4GL) techniques and requires well defined requirements

(+) rapid (60-90 days), (-) requires commitment from all parties, sufficient human resources, the right type of application

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

team #1team #2 team #3

60 - 90 days

Evolutionary ModelsEvolutionary Models

Many systems evolve over time.

A process which develops increasingly more complete versions of the software is called for.

Unlike sequential because of iteration

Unlike prototyping because don’t throw away

The Incremental ModelThe Incremental Model

Deliver increasing functionality at each increment. First iteration is the core. (+) manages risk, deals well with staffing problems, (-) can be slow

increment 2

increment 3

increment 4

increment 1

delivery of1st increment

delivery of2nd increment

delivery of3rd increment

delivery of4th incrementcalendar time

analysis design code test

analysis design code test

analysis design code test

analysis design code test

The Spiral (Boehm) ModelThe Spiral (Boehm) Model

Each turn has 3-6 task regions. Unlike incremental model software development requires the entire spiral

(+) considers entire software life cycle, good for large scale projects, (-) requires risk assessment expertise, not as widespread

Customer Communication

PlanningRisk Analysis

Engineering

Construction and ReleaseCustomerEvaluation

The Component-Based (OO) ModelThe Component-Based (OO) Model

Similar to spiral but uses pre-packaged classes wherever possible (+) emphasises reuse, (-) must design with further reuse in mind

look-upclasses

in library

extractclasses

if available

engineerclasses

if unavailable

constructnth iteration

of system

put newclasses

in library

OO analysisOO designOO programmingOO testing

identifycandidateclasses

Customer Communication

Planning Risk Analysis

Customer Evaluation

Engineering, Construction & Release

Other Process ModelsOther Process Models

Concurrent process model: recognizes that different stages of the project (analysis, design, coding) will have achieved different states (e.g. under development, awaiting changes, done, etc.)

Formal methods: the process to apply when a mathematical specification is to be developed

Cleanroom software engineering: emphasizes error detection before testing. A variation of formal methods.

The Object Oriented ParadigmThe Object Oriented Paradigm

Object technologies reuse faster software development and higher quality

Object oriented software is easier to maintain because the structure is inherently decoupled

Employ the component-based process model to identify re-usable components

For some systems, there may be an obvious mapping from real world entities to system objects

The OO MindsetThe OO Mindset

problem domainproblem domain

objectsobjects

ClassesClasses

object-oriented thinking begins with the definition of a class often defined as: template

generalized description

pattern

“blueprint” ... describing a collection of similar items

a metaclass (also called a superclass) is a collection of classes

Classes bundle together attributes (data), methods (algorithms) and messages (communication)

once a class of items is defined, a specific instance of the class can be created (an object)

Inside ObjectsInside Objects

sender object

attributes:

methods:

receiver object

attributes:

methods:

message: [receiver, operation, parameters]

message:

[sender, return value(s)]

Key OO ConceptsKey OO Concepts

Encapsulation: Data and operations on the data are packaged together. This enables: reuse of the object as a system component. information hiding where the user is shielded from internal

implementation details. simpler communication

Inheritance: A subclass inherits the attributes and methods of its superclass and can extend them. This enables: Easy extension for reuse But beware of multiple inheritance

Polymorphism (overloading): A number of different operations in different classes (often sharing a super-class) can have the same name. This enables: Further decoupling of communication