SoftwareEngg2012 Lecture 05

Software EngineeringBS (Computer Science)

1

Lecture-05Date: 10-03-2012

Dr. S. N Ahsan

Layout• Review

• Software Metrics

08.10.2011 Dr. S. N Ahsan, IQRA-University 2

Review


Software Process Models• Prescriptive Process Models

1. Waterfall model (Royce, 1970)• V-Model: The V-model depicts the relationship of quality assurance

actions to the actions associated with the different step of waterfall model

2. Incremental Process Models3. Evolutionary Process Models

• Prototyping• Spiral model (Boehm, 1988)

4. Concurrent Models

• Specialized Process Models1. Component Based Development2. The Formal Methods Model3. The Unified Process Model


‘Rules of Thumb’ about approach to be used

IF uncertainty is highTHEN use evolutionary approach

5

IF complexity is high but uncertainty is notTHEN use incremental approach

IF uncertainty and complexity both lowTHEN use one-shot

IF schedule is tightTHEN use evolutionary or incremental

Specialized Process Models

Component based Development:

The process to apply when reuse is a development objective Unified Process:

A “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

Formal methods:

Emphasizes the mathematical specification of requirements

SWE 418 (062) Software Process Models 6

Component Based DevelopmentCOTS or Commercial Off-The-Shelf components are becoming more available. Most (not all) COTS components have targeted functionality with good interfaces that enable the component to be integrated.

Examples:

Software:

• Operating Systems (UNIX, Windows/NT, OS2)

• Databases (Oracle, Sybase)

• Graphics Packages (Motif, ??)

Hardware:

• Processors (Motorola, HP, Sun, Intel)

• Disk Drives (Western Digital, Red Rock)

• Peripherals (Printers, Monitors, Keyboards, etc.)


Unified Process Models

• A “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

08.10.2011Dr. S. N Ahsan, IQRA-

University8

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

Agile Development

• Agile Software Engineering combines a philosophy and a set of development guidelines. – The philosophy encourages customer satisfaction and

early incremental delivery of software,

– Small highly motivated project teams

– Informal method

– Minimal Software Engineering work products

– Development simplicity

• What is Agility?

– Quick and effective response to change

9

XP Practices (1-12)

1. Planning game2. Small releases3. Metaphor4. Simple design5. Testing6. Refactoring7. Pair-programming7. Collective ownership8. Continuous integration9. 40-hour week10. On-site customer11. Coding standards

19.04.23 Dr. S. Nadeem Ahsan, IQRA-University 10

Refactoring

Refactoring: changes to the organization of a program, not its function. Behavior preserving program transformations.

Why Refactoring is Important: Only defense against software decay. Often needed to fix reusability bugs. Lets you add patterns after you have written a program; lets you

transform program into framework. Lets you worry about generality tomorrow; just get it working today.

Pair Programming: Experience the Difference

Laurie Williams

North Carolina State University

Robert Kessler

University of Utah

Pair Programming Driver and Navigator working together on one task Roles changing often. Collective responsibility for outcome. Bringing together of multiple perspectives, experiences, abilities, and

expertise

Why Pair:

– Higher quality code

– Faster cycle time

– Enhanced trust/teamwork

– Knowledge transfer

– Enhanced learning

– More fun

Pair Programming

© Williams/Kessler 2004

This is NOT Pair Programming

Post Development Test Cases Passed

0.0%10.0%20.0%30.0%40.0%50.0%60.0%70.0%80.0%90.0%

100.0%

Program 1 Program 2 Program 3 Program 4

Individuals

Collaborators

Elapsed Time

0.0%

20.0%

40.0%

60.0%

80.0%

100.0%

120.0%

Program 1 Program 2 Program 3

One Individual One Collaborator

Pair Programming: A Historical Perspective

. . . 1995

1996 1997 1998 1999

2000

2001

Hill Air Force Base:

“Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 lppm . . .

The error rate through software-system integration was three orders of magnitude lower than the organization's norm . . .

A brief list of observed phenomena includes focused energy, brainstorming, problem solving, continuous design and code walkthroughs, mentoring and motivation.”

http://www.bertola.org/essays/airforce/f102a.jpg

Formal Method

Formal methods allow a software engineer to create a specification that is more complete, consistent, and unambiguous than those produced using conventional or object oriented methods. • Set theory and logic notation are used to create a clear statement of

facts (requirements).

• This mathematical specification can then be analyzed to prove correctness and consistency.

• Because the specification is created using mathematical notation, it is inherently less ambiguous than informal modes of representation.


What is Formal Methods?

Formal methods = Formal Specification

+

Refinement

+

Formal Verification

Set theory, logics, algebra, etc.

Shaoying Liu

形式的手法

Shaoying Liu

形式的手法

Formal Specification and Verification

• Formal methods can be applied at various points through the development process

– Specification

– Verification

• Specification: Give a description of the system to be developed, and its properties

• Verification: Prove or disprove the correctness of a system with respect to the formal specification or property

Specification

• Formal methods for specification of the concurrent systems

– CSP (Hoare 1985)

– Temporal Logic (Pnueli 1981)

– I/O Automata (Lynch and Tuttle 1987)

Verification

• Two well established approaches to verification

– Model Checking

– Theorem Proving

• Model checking

– Build a finite model of system and perform an exhaustive search

• Theorem Proving

– Mechanization of a logical proof

Example of Formal Specification

• Consider the following constructive specification example:

• The specification has three components

1. A signature

2. A Predicate (a boolean expression)

3. Terms n

• Another example :


A Case Study: Block Handler



Block Handler (Formal Specification)

Coupling and Cohesion

Characteristics of Good Design: High cohesion Low coupling

No dependencies Loosely coupled-some dependencies

High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the component is connected.

Cohesion: The degree to which all elements of a component are directed towards a single task and all elements directed towards that task are contained in a single component.

Coupling:

Programming Paradigms Procedural programming

Executing a set of commands in a given sequence Fortran, C, Cobol

Functional programming Evaluating a function defined in terms of other functions Lisp, ML, OCaml

Logic programming Proving a theorem by finding values for the free variables Prolog

Object-oriented programming (OOP) Organizing a set of objects, each with its own set of responsibilities Smalltalk, Java, C++ (to some extent)

Aspect-oriented programming (AOP) Executing code whenever a program shows certain behaviors AspectJ (a Java extension) Does not replace O-O programming, but rather complements it

28

Aspect Oriented Programming

Aspect Oriented Programming (AOP) is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns. AOP forms a basis for aspect-oriented software development.

AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, while "aspect-oriented software development" refers to a whole engineering discipline.


Crosscutting Concerns• AOP addresses behaviors that span many, often

unrelated, modules.– Core Concerns:

• Primary core functionality.• Central functionality of a module.

– Crosscutting Concerns:• System wide concerns that span multiple modules.• Cuts across the typical division of responsibility.

– OOP creates a coupling between core and crosscutting concerns.

– AOP aims to modularize crosscutting concerns.


Aspects

• In AOP crosscutting concerns are implemented in aspects instead of fusing them into core modules.

• Aspects are an additional unit of modularity.

• Aspects can be reused.

• By reducing code tangling it makes it easier to understand what the core functionality of a module is.

• An “aspect weaver” takes the aspects and the core modules and composes the final system.


Terminology cont

• Core concerns– Central functionality of a Business logic (single module)– Customer and Account management, Interbanking

transactions, ATM transactions• Crosscut concerns

– System-level, peripheral requirements (multiple modules)– Persistence of all entities, Transaction integrity,

Authorization of access to various services, logging, Security, Error checking, Policy enforcement

19 August 2005 Aspect Oriented Programming 32

AOP Methodology

• The idea behind AOP is “Separation of concern”

• AOP builds upon Existing Methodologies (OOP, Procedural programming), augmenting them with concepts and constructs in order to modularize crosscutting concerns.

• Now, concern consists of what?

19 August 2005 Aspect Oriented Programming 33

AOP Methodology

Cross Cutting Concerns


Cross Cutting Concerns


Case Studies


Software Application

• Procurement Management System

• Human Resource Management Package

• PLC based Industrial Control System

Software Metrics


39

A Good Manager Measures

measurementmeasurement

What do weWhat do weuse as ause as abasis?basis? • • size?size? • • function?function?

project metricsproject metrics

process metricsprocess metricsprocessprocess

productproduct

product metricsproduct metrics

40

Why Do We Measure?

• assess the status of an ongoing project

• track potential risks

• uncover problem areas before they go “critical,”

• adjust work flow or tasks,

• evaluate the project team’s ability to control quality of software work products.

Measure, Measurement and Metrics• A measure provides a quantitative indication of the

extent, amount, dimension, capacity, or size of some attribute of a product or process.

• Measurement is the act of determining a measure. Example: the number of errors in a system is a measurement.

• A Metric is a measurement of the degree that any attribute belongs to a system, product or process. Example: the number of errors per person hours would be a metric.

Why Measure Software?

• Determine the quality of the current product/process/project

• Predict qualities of a product/process/project

• Improve quality of a product/process/project

• Assess the status of an ongoing project & track potential risks

Measurement Principles

1. Formulation

2. Collection

3. Analysis:

4. Interpretation

5. Feedback

Metric Classification

1. Products Metrics:I. Size Metrics (LOC and Function Points)II. Halstead’s Product Metrics III. Complexity Metrics

2. Object Oriented Metrics3. Processes4. Project

Product MetricsSize Metrics: LOC Metrics

• Size of the software produced

• LOC - Lines Of Code

• KLOC - 1000 Lines Of Code

• SLOC – Statement Lines of Code (ignore whitespace)

• Typical Measures:

– Errors/KLOC, Defects/KLOC, Cost/LOC, Documentation Pages/KLOC

LOC (Pros & Cons)

Size Metrics: Function Point Metrics

A conceptual measure of software size based on functional requirements

– Basis is the measured proportions of effort required to produce types of functionality

•Function Point: A measure which represents the functional size of application

•Function Point Analysis: A standard method for measuring software development and maintenance from the customer’s point of view.

•Function Point Count: The function point measurement of a particular application or project

FP = count total × [0.65+0.01 × Σ(Fj)]

Function Point Metrics

• Using FPA to help manage a software project can improve the probability of completing a project

Evaluating the Economics of a Project

One software project, coded in 3-different languagesOne software project, coded in 3-different languagesSLOC metrics can be misleadingSLOC metrics can be misleading

19.04.23 Dr. S. Nadeem Ahsan, IQRA-University 50

Function Point Metrics are Comparable and Logical across Projects , Platform and Languages

Example of Function Point Metrics (FP)

A data flow model for SafeHome Software

Example of Function Point Metrics (FP)

FP= 50× [0.65+0.01 ×46]=56

Documents

SoftwareEngg2012 Lecture 05