1: Software Development and .NET An approach to building software - - PowerPoint PPT Presentation

1: Software Development and .NET

An approach to building software

Overview

Programming in software development Life-Cycles for software development Object-orientation and modelling Requirements analysis and specification Algorithms Task decomposition The .NET framework

Programming

Programming is only one activity in the process of

developing software

Analogous to the Construction phase in building (i.e. missing out

architecture, surveying, logistics etc.)

Before programming can commence, we need to determine what

to do (requirements analysis) and how we will do it (design)

To build good software, it is necessary to perform a lot of

• rganizational tasks – breaking up the overall job,

deciding on what will be implemented, combining components into a system, testing what we have built etc.

Software Life-Cycle

Most software developers accept that

software is created over a sequence of tasks that are often called the ‘life-cycle’

Depending on the required system, the

tools used, the developers doing it and

• ther environmental factors, any one of

many different styles of life-cycle can be used

Common Life Cycle Models 1

The Waterfall Model

Well established Predictable Easy to cost But… Inflexible Software appears late

Common Life Cycle Models 2

Staged Delivery

Software Concept Requirements Analysis Architectural Design Stage 1: Detailed design, code, debug, test and delivery Stage 2: Detailed design, code, debug, test and delivery Stage n: Detailed design, code, debug, test and delivery

Based on Waterfall Good for complex systems with many independent components Quick to get working Initial design is simple But… Can cause ‘feature creep’

Common Life Cycle Models 3.

Evolutionary prototyping

Initial Concept Design and implement partial prototype Refine prototype until acceptable Complete and release prototype

Based on a cycle of rapid design, build, evaluate, modify design etc. Good for systems where requirements are ambiguous (e.g. new type

• f software)

Customer involved throughout But… Difficult to predict Duration Cost

Common Life Cycle Models 4

Extreme Programming (XP)

A radical and very recent development model Eschews traditional phase-oriented approach, reasoning that requirements are impossible to freeze early in a project’s life Promotes a set of practices based on programmer’s experience: Small teams Form of Staged/Evolutionary Delivery, but many more stages (mini-milestones) Team MUST include a client representative – developers require constant access to clarify requirements and demonstrate stages of delivery Team agrees of code standards, which are held rigidly Development progresses as: Define a requirement (a story) Devise a test of the requirement Write software to pass the test (simple as possible)

Life Cycles in Practice

There are in fact many more forms of life-cycle than the

4 described here

See Rapid Development, by Steve McConnell for an overview of

the main ones

Most SD companies have their own variation on a

common life cycle

Corporate culture is a major influence on how a life-cycle model

is applied to a real project

It is common to ‘mix-and-match‘ aspects of the standard

life-cycles described in text and research papers

e.g. Staged Delivery with an Evolutionary approach in problem

stages

There is no ‘one-size-fits-all’ approach to building

software

Life-cycle – Influencing factors

Size of project the number of people involved in the project the size of the company employing the

developers

the level of formality adopted by the company the type of software being developed the expertise and experience of the developers, the knowledge that the customer or end-user has

about software and software development

The customers’ and developers’ understanding

• f the nature of the proposed software

Life-Cycle for building OO programs in Visual Basic – requirements:

support for an object-oriented development model support for the ‘Visual’ development model espoused by

Visual Basic (and several other development systems)

scalability – that is, a facility to enable the use of the life

cycle model for projects in a range of sizes

ease of use – we have no wish to wrap up an already

complex task in layers of bureaucracy

best use of the high adaptability and rapid-development

features inherent in object-oriented programming and visual development

Object Orientation

A Life-Cycle is a process model that does

not take the detailed nature of the project into account

A life-cycle model is not specifically ‘object-

• riented’

Individual phases will be affected, since the

• utput of each phase is some form of

software analysis/design/implementation product

Modelling and Designing Software

Many established software design

methods

Typically, a set of standards for diagrams,

charts, tables etc. that can be used to describe software

UML is the current industry standard

Well established Flexible Provides sufficient detail for many types of

software project

UML

Unified Modelling Language – the integration of

several design techniques useful in software development

Diagram based, since engineering

communications work better using ‘visual’ models

Software tools (e.g. Visio, Rational Rose) can

be used to create the framework of a program from a UML model

CASE (Computer-Based Software Engineering) Faster development Fewer human errors Reduction of ‘drudgery’ in programming

UML and Software Products

A series of Diagram standards for describing

various stages in the development of software

UML’s 4+1 View model

Use-case view – for defining requirements Design view – for defining the logical structure of

software

Implementation view – describes physical

components of system

Process view – depicts the ways different elements

interact

Deployment view – describes how the various

physical components are organised (e.g. how parts are allocated across a network).

Requirements Analysis & Specification

Need to find out what a computer system will be

required to do

Information comes from:

Initial proposal statement Interviews with customers/end users Developers’ knowledge and experience Analysis and observation of manual system (e.g. for office

software)

Determining inputs and desired outputs

Result of all this analysis is a specification document,

containing statements that say what the system is expected to do in general terms

Typically a Use-Case diagram

Use-Cases and Use-Case Diagrams

Use-Case view

Depict a system from

an end-user’s perspective

Creates a model of the

‘functions’ (use-cases) a system will perform

Provides a starting

point from which to determine the objects that will make up a system

Use-cases are

‘scenarios’ that require detailed descriptions

A ‘Use-Case Diagram’ is

a shorthand view of these

Travel Agency System Travel Agent Exchange Clerk

Add Customer Details Book Package Holiday Retrieve Booking Data Retrieve Customer Data Exchange Currency Generate Invoice

Objects and Requirements

From a full description of system requirements, we need to

determine the components a system will be made up of

These are ‘Objects’ in OOP terminology

The manufactured world is full of objects, many of which are

components of bigger objects

We need to know what they are, what they must be capable of, and how

they will need to interact

E.g. a pen has a body, an ink reservoir, a nib and ink, each with

properties (ink is blue) and operations (ink runs out, nib transfers ink to paper)

Software objects are made up of data (properties) and operations

(methods). Operations execute in response to external stimuli (messages)

Several objects may collaborate to meet any given system

requirement

Objects and Classes

A Class is a design (or template) for a type of

• bject

Efficient – design once, deploy many times An object is an Instance of a class

Classes are designed to:

Represent ‘parts’ of a system, e.g.

A Printing sub-system An Invoice A Customer Record

Define objects that can interact in functional ways

A Customer may be associated with a number of invoice The Printing sub-system can print an Invoice

(Much) more on this later

Algorithms

All software is built on the basis of a computer

following simple instructions

Could be to extract data from a disk file, perform

some arithmetic, display a result

Objects are convenient ways of organising sets

• f instructions

Easier to conceptualise – e.g. a Customer can print

an Invoice (using the Printer sub-system)

The actual instructions are defined as Algorithms

An algorithm is a set of instructions for solving a

problem or task. When the instructions are followed, it must eventually stop with an answer

Algorithms and Tasks

Many algorithms are described in texts and

research papers, and many have been handed down for hundreds of years (e.g. Euclid’s algorithm for finding the GCD of two numbers)

Typically these are descriptions of mathematical

calculations or logical manipulations

In a lot of cases, a computer algorithm is simply

a translation of the manual way of doing a job

e.g. filling in a tax form (which is even depicted like an

algorithm in the tax form itself)

e.g. following a recipe

The main principle is that an algorithm is simple

to follow

The clever bit can be in devising it

Task Decomposition

One approach to describing a task as an

algorithm is to perform Task Decomposition (a.k.a. Stepwise Refinement)

Break a complex task into a number of smaller sub-

tasks

If the sub-tasks are still complex, consider each to be

a separate task and go back to previous step

This simple approach (also an algorithm) is the

basis used for solving most computer programming problems

VB .NET for creating software

Visual Basic .NET is a programming language that is

used to build Software Solutions

A Solution is an applications program, that can be composed of

• ne or many Assemblies

An Assembly is either a program or a program component that

can be used by other programs. As the name suggests, an Assembly is typically composed of a number of separate items, each of which occupies a Visual Basic Code file. A Project is a combination of code files, that is used to create an Assembly

Visual Studio allows you to work on single Projects and

complete, multi-project Solutions.

A Project can be a stand-alone program, or a component that

can be used with several programs. Each project in a solution defines a separate Assembly

Visual Studio

VS Solution VB Project

Components of a Solution

Visual Basic Compiler Code File Code File Code File Assembly Assembly Assembly

Summary

There is more to software development than

programming

Life-Cycles Modelling and Design UML Requirements analysis and Use-Case diagrams Classes and Objects Algorithms Task Decomposotion .NET Projects and Solutions