CS3500 Software Engineering

CS3500 Software Engineering

Object-Oriented Analysis & Design (2)

account_balance

withdraw

depositBalance enquiry

account_balance

deposit

withdraw

Balance_enquiry

message

message

message

Traditional view Object-oriented view



Well-designed units are independent units!

Everything in the software that relates to that part of the real world modeled by that object can be found in the object itself!

Encapsulation!

Information-hiding! Read!

Note in the previous diagram how everything (operations & data) to do with account_balance is contained within the object.

This is not the case in the classical view and in how an implementation would have been done before OO



Object-oriented uses the Unified Modeling Langauage (UML) for

specifying visualising constructing, and documenting

all system components.

This means that the same methodology carries through the SD process from beginning to end.

This is in real contrast to other approaches where the methods/techniques used in analysis & design are very different from those used in documenting code.

Exploratory Programming (4)



UML provides several different kinds of diagrams for defining different things about

objects,

interaction between objects and

processes (methods) which operate on objects.

(Class diagrams, use case diagrams, sequencediagrams, collaboration diagrams, statechart diagrams, activity diagrams, component and deployment diagrams).

Methods provide “services” on objects.

The services (functions) provided by methods is achieved by message-passing between objects.


Exploratory Programming (4)Object-Oriented Analysis & Design (6)

In summary:

The OO approach provides a consistent methodology andset of techniques that serve the developer from project inception through to delivery.

OO supports encapsulation and therefore information-hiding.

New data types can be defined as extensions of previously defined types rather than having to be defined as totally new ones

Post-delivery maintenance is greatly simplified.

OO reduces the level of complexity of a product and therefore simplifies both development and maintenance.

OO promotes reuse: because objects are independententities they can be utilised in future products.

Read about inheritance


Exploratory Programming (4)Object-Oriented Analysis & Design (7)

OO compared to Classical?

An IBM survey in 1994 of 3 different projects showed that the OO model outperformed the classical approach in every respect.

Specifically, there were -

major decreases in the number of faults detected,

far fewer change requests during both development and maintenance and

significant increases in ease of maintenance.

A report in 2000 surveyed 150 U.S. software developersto determine attitudes towards OO – 96 who used OO and 54 who still used classical approaches.

Both groups felt the OO model was superior.


Exploratory Programming (4)Formal Specification (1)

Formal methods allow a software engineer to create a specification that is more

complete

consistent, and

unambiguous

than that produced by any other means developed to date.



Set theory and logic notation are used to create a clearstatement of facts (requirements).

This mathematical specification can then be analysedto prove correctness and consistency.

Formal methods reduce specification errors dramatically.

Because of this, formal methods are mainly used in safety-critical systems where system failurecan have a high price(e.g. software embedded in life-support systems, traffic control systems, environmental control software, etc.)

System failure unacceptable



Several techniques are available for formal specification:

The Z specification language

Vienna definition method (VDM)

Finite state machine analysis

Petri net analysis


Formal Specification (4)

Formal specification requires that a process or function is defined (using some mathematical notation) in terms of

the state of all data before the function executes,

the transforming steps of the function,

the state of all data after the function has executed, and

any constraints that apply.

As such, a formal specification can be proved to be correct while an informal specification can not.


Formal Specification (5)

Formal specification focuses mainly on function and data.

Timing, control and behavioural aspects of a problem (as well as human-machine interfaces) are better specified using graphical techniques.

Applying formal specification to a project is time-consuming. Also expensive because required skills are in short supply.

Accordingly, use of formal methods still generally restricted to safety-critical systems.


Reuse (1)(System construction with re-usable components)

Stephen Schach wrote:

“If reinventing the wheel were a criminal offence, many software professionals would be languishing in jail.”

Facts:

There are thousands of different COBOL payroll programs, all doing essentially the same thing.

The world needs just one (or a few) payroll program that can run on a variety of hardware and be tailored/configured to match the specific needs of a particular organisation.

This re-invention is the main cause of the sheer size of the legacy problem.


Reuse (2)

Building software by reuse means using componentsof one product to help in the building of another product with a different functionality.

A reusable component need not necessarily be a moduleor piece of code – it could be a design document, part of a manual, a set of test data, or a time or cost estimate.

Developers realisethat a piece of a previously developedproduct can be reusedin a new product

Opportunistic(or accidental) =reuse

Systematic(or deliberate) =reuse

Utilisation of components constructed specificallyfor possible futurereuse

Software Component LibraryCS3500 Software Engineering

Reuse (2)


Reuse (2)

G H

KJI

FE

A DCB

L

SRQ

PONM

T

K

P

T

N

IL

R

J

F

I

C

K

E

E

NE

T

K

I

P

L

New 1

New 4

New 3

New 2

Software Product 1

Software Product 2

New 4

New 3

New 2

New 1


Reuse (3)

By the 1970’s people began to realise that there was no need to construct new code from scratch each time aninput-output routine, or a routine for computing sines and cosines was required.

Now, we are familiar with the availability of libraries ofroutines (methods, functions, etc) which we can use whenprogramming in C++, Java or other languages.

Class libraries are available to make life easier for object-oriented programmers.

Despite this, there has been a slow take-up of reusability asa mainstream SD strategy among application developers

The idea of libraries of subroutines has been extended to large statistical libraries such as SPSS and numerical analysis libraries like NAG.


Reuse (4)

Points to note:

On average, only about 15% of any software product serves a truly original purpose

The other 85% of the product could, in theory, be standardised and reused In future products.

Some organisations achieve reuse rates approaching 40%

Why do so few organisations employ reuse to shorten the development process?


Reuse (5)

Impediments to Reuse

Many software professionals prefer to rewrite a routine from scratch rather than reuse a routine written by someone else(also know as the NIH or not invented here syndrome!)

Developers often suspicious that reusing software components might introduce faults into the product

Reuse can be expensive - estimates vary from 11% to 480% cost increases to make a component reusable compared to original construction cost of that component

Legal issues could arise, e.g. developer uses a component from a product built for client A in a new product for client B …

For COTS (commercial off-the-shelf) components source code rarely available so COTS components have limited modifiability.


Reuse (6)

The Future:

The current focus on

objects and methods,

encapsulation and information-hiding,

component-based software systems and the growing availability of well-tested libraries of routines

should promote reuse and offers greater promise for time-efficient delivery of fault-free software products than is seen in the other SD models now in use.


Software Quality (1)

Software quality has to be the focus and the SD model chosen for a project does not, in itself guarantee quality.

In 1977, McCall identified 9 criteria which could provide the basis for measuring software quality. (Factors in Software Quality)



The McCall Quality Factors

Correctness – the extent to which software is consistent with its specification and matches the customer’s needs

Reliability – the probability of failure-free operation of software in a specified environment for a specified time

Maintainability & Flexibility – the effort (work + resources) required to fix errors & make changes in software

Testability – the effort (work + resources) required to test software

Usability – the effort required to become a competent operator of a software system, (operation & configuration, data input preparation, output checking and interpretation)



The McCall Quality Factors (cont)

Efficiency – the amount of computing resources and code required by a software system to perform its functions in the shortest possible time

Reusability – the extent to which components of a software system can be used in other applications

Inter-operability– the effort required to couple (link) one piece of a software system to another, or to another separate system

Portability – the effort needed to move software and re-install/configure it on a different hardware platform and/or operating system



McCall Factors & Metrics

The McCall factors are not in themselves measurements.

It isn’t useful (from a quality viewpoint) to say that a piece of software is “very reliable”, “nice to use”, or “easy to maintain”.

These are entirely qualitative (and non-quantitative) subjective statements.

The McCall factors are useful because they identify those criteria around which metrics can be built.

A “metric” is a measurement (with a mathematical basis) of some particular aspect of software

Many different metrics can be developed for each of the McCall factors

Documents

CS3500 Software Engineering