Software Engineering COMP 201

Software EngineeringCOMP 201

1COMP201 - Software Engineering

Lecturer: Sebastian CoopeAshton Building, Room G.18

E-mail: [email protected]

COMP 201 web-page:http://www.csc.liv.ac.uk/~coopes/comp201

Lecture 3 – Software Processes

Recap from Last Lecture: Generic Software Process ModelsThe Waterfall Model

Separate and distinct phases of specification and development

Evolutionary DevelopmentSpecification and development are interleaved

Formal Systems Development (example - ASML)A mathematical system model is formally transformed to

an implementationIterative development (most widely used)

The system is built up in a series of steps


Software SpecificationSoftware Specification: The process of establishing what

services are required and the constraints on the system’s operation and development

Requirements Engineering ProcessFeasibility studyRequirements elicitation and analysisRequirements specificationRequirements validation


The Requirements Engineering Process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument


Software Design and ImplementationThe process of converting the system specification into an executable system

Software designDesign a software structure that realises the specificationTasks .. Design database, website design, data structures,

communications protocolsImplementation

Translate this structure into an executable program

The activities of design and implementation are closely related and may be inter-leaved


Design Process ActivitiesArchitectural design (separate web service modules)

The sub-systems making up the system and their relationships are identified and documented.

Abstract specificationFor each sub-system, an abstract specification of its

operational constraints and services is produced.Interface design

For each sub-system, an unambiguous interface with other sub-systems is designed and documented Formal specification may be used in this stage (we study this later)


Design Process Activities

Component designServices are allocated to components and the interfaces of

these components are designedData structure design

The data structures used in the system implementation are designed in detail and specified

Algorithm designThe algorithms used in components to provide services are

designed and specified


An Example SystemConsider the scenario of developing a Coffee/drinks

machine softwareWhat are the major sub-systems?

Graphical display, cash handling, accounting, safety system, recipe handling, stock control

How may we define an abstract specification for each? How do the different sub-systems interact?

Can you define specifications for components/data structures and algorithms for one of the sub-systems?

COMP201 - Software Engineering 8

The Software Design Process

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products


ModelsGraphical views of the operation/structure of the systemCan be dynamic or staticWhy have models

Formalizes the type and format of required informationEasier to get the big picture than text documentsDo not rely heavily on natural language to be understoodSome, can be translated automatically to software

implementationCan be tested for validity automatically


Design MethodsDesign (structured) methods are systematic

approaches to developing a software design

The design is usually documented as a set of graphical models

Possible models (we study these in detail in later lectures)Data-flow modelEntity-relation-attribute model (data base or class design)Structural modelObject models A state transition model showing system states and triggers


Programming and DebuggingProgramming and Debugging consist of translating a

design into a program and removing errors from that program

Programming is usually personal activity - there is no generic programming process, but there are good programming practices and organisational standards to be followed.

Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process


Good programming is iterative

Write a very small piece of codeDetermine it works (test it)Archive itAdd little bit to code, test itArchive itAdd little bit to code, test it

Etc. etc.


The Debugging Process

Locateerror

Designerror repair

Repairerror

Re-testprogram


Debugging in real world

Ideally the software fault can be re-produced at willSome software faults indicate problems with overall

software design and require application re-designe.g. lack of thread safety

If bugs hard or impossible to re-produce in test conditionsInsert debug/test code embedded into product which logs

and alerts in fault conditionsAdd patch code, which will help recover in fault conditions

Example catching exceptions and logging


Software Validation

Verification and validation is intended to show that a system conforms to its specification (verification) and meets the requirements of the system customer (validation)

Involves checking and review processes and system testing

System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system


The Testing Process

Sub-systemtesting

Moduletesting

Unittesting

Systemtesting

Acceptancetesting

Componenttesting

Integration testing Usertesting


Testing StagesUnit testing

Individual components are testedModule testing

Related collections of dependent components are testedSub-system testing (merges with system testing)

Modules are integrated into sub-systems and tested. The focus here should be on interface testing

System testingTesting of the system as a whole. Testing of emergent

propertiesAcceptance testing

Testing with customer data to check that it is acceptable


Testing mapped to OO programming

Unit testing (class/method level)Testing an individual classes methods

Module testing (interleaved with unit testing)Testing classes which integrate with other classes

Sub-system testingA number of classes tested which produce a given service

(example card payment services, SMS sending services)Organised as package or JAR library

System testTest whole system


Testing Phases

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

Service Acceptancetest

Systemintegration test

Sub-systemintegration test


Note test depends on specification

Software EvolutionSoftware is inherently flexible and can change. As requirements change through changing business

circumstances, the software that supports the business must also evolve and change

Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new

It is important to realise that maintenance costs are sometimes several times the initial development costs of the system.


System Evolution

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems


Automated Process Support (CASE)(see COMP220/285 Semester 2)

Computer-aided software engineering (CASE) is software to support software development and evolution processes

Activity automation:Graphical editors for system model developmentData dictionary to manage design entitiesGraphical UI builder for user interface constructionBug/Issue management toolsVersion control management toolsDebuggers to support program fault findingAutomated translators to generate new versions of a program


Case TechnologyCase technology has led to significant improvements in the software process though not the order of magnitude improvements that were once predicted. Why is this?

Software engineering requires creative thought - this is not readily automatable and the use of artificial intelligence to provide support for design has not been successful.

Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support such activities


CASE ClassificationClassification helps us understand the different types of CASE tools and their support for process activities

Functional perspectiveTools are classified according to their specific function

Process perspectiveTools are classified according to process activities that are

supportedIntegration perspective

Tools are classified according to their organisation into integrated units


CASE IntegrationTools (Bugzilla, GIT)

Support individual process tasks such as design consistency checking, text editing, etc.

Workbenches (Rational Rose UML)Support a process phase such as specification or design,

Normally include a number of integrated toolsEnvironments (example IDE like Eclipse)

Support all or a substantial part of an entire software process. Normally include several integrated workbenches


Lecture Key PointsRequirements engineering is the process of developing a

software specificationDesign and implementation processes transform the

specification to an executable programValidation involves checking that the system meets its

specification and user needsEvolution is concerned with modifying the system after it

is in useCASE technology supports software process activities


Software Engineering COMP 201

Documents

Transcript of Software Engineering COMP 201