Software Engineering

BS (Computer Science)

Lecture-05
Date: 10-03-2012

Dr. S. N Ahsan
1

Layout
Review Software Metrics

08.10.2011

Dr. S. N Ahsan, IQRA-University

Review

08.10.2011

Dr. S. N Ahsan, IQRA-University

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. 3.

Incremental Process Models Evolutionary Process Models

Prototyping Spiral model (Boehm, 1988)

4. 1. 2. 3.

Concurrent Models Component Based Development The Formal Methods Model The Unified Process Model

Specialized Process Models

08.10.2011

Dr. S. N Ahsan, IQRA-University

Rules of Thumb about approach to be used

IF uncertainty is high THEN use evolutionary approach IF complexity is high but uncertainty is not THEN use incremental approach IF uncertainty and complexity both low THEN use one-shot IF schedule is tight THEN 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

Component Based Development

COTS 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.)

08.10.2011

Dr. S. N Ahsan, IQRA-University

Unified Process Models

A use-case driven, architecture-centric, iterative and incremental software process closely aligned with the Unified Modeling Language (UML)
UP Phases
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows Requirements Analysis Design

Implementation Test Support Iterations #1 #2 #n-1 #n

08.10.2011

Dr. S. N Ahsan, IQRAUniversity

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

XP Practices (1-12)
1. 2. 3. 4. 5. 6. 7. 7. 8. 9. 10. 11.
06.03.2014

Planning game Small releases Metaphor Simple design Testing Refactoring Pair-programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards
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

This is NOT Pair Programming

Williams/Kessler 2004

Post Development Test Cases Passed

100.0% 90.0% 80.0% 70.0% 60.0% 50.0% 40.0% 30.0% 20.0% 10.0% 0.0% Program 1 Program 2 Program 3 Program 4

Individuals Collaborators

Elapsed Time
120.0% 100.0% 80.0% 60.0% 40.0% 20.0% 0.0% Program 1 Program 2 One Individual One Collaborator Program 3

Pair Programming: A Historical Perspective

...

199 5

1996

199 7

199 8

199 9

200 0

200 1

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.

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.

08.10.2011

Dr. S. N Ahsan, IQRA-University

19

What is Formal Methods?

Formal methods = Formal Specification + Refinement + Formal Verification

Set theory, logics, algebra, etc.

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 :

08.10.2011

Dr. S. N Ahsan, IQRA-University

24

A Case Study: Block Handler

08.10.2011

Dr. S. N Ahsan, IQRA-University

25

Block Handler (Formal Specification)

08.10.2011

Dr. S. N Ahsan, IQRA-University

26

Coupling and Cohesion

Characteristics of Good Design: High cohesion Low coupling Coupling: 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.

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.

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 crosscutting concerns. AOP forms a basis for aspectoriented 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.

08.10.2011

Dr. S. N Ahsan, IQRA-University

29

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.

08.10.2011

Dr. S. N Ahsan, IQRA-University

30

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.

08.10.2011

Dr. S. N Ahsan, IQRA-University

31

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

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

Cross Cutting Concerns

08.10.2011

Dr. S. N Ahsan, IQRA-University

34

Cross Cutting Concerns

08.10.2011

Dr. S. N Ahsan, IQRA-University

35

Case Studies

08.10.2011

Dr. S. N Ahsan, IQRA-University

36

Software Application
Procurement Management System

Human Resource Management Package

PLC based Industrial Control System

Software Metrics

08.10.2011

Dr. S. N Ahsan, IQRA-University

38

A Good Manager Measures

process

process metrics project metrics measurement product metrics

product

What do we use as a basis? size? function?

39

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 teams ability to control quality of software work products.

40

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. 2. 3. 4. 5. Formulation Collection Analysis: Interpretation Feedback

Metric Classification
1. Products Metrics:
I. Size Metrics (LOC and Function Points) II. Halsteads Product Metrics III. Complexity Metrics

2. Object Oriented Metrics 3. Processes 4. Project

Product Metrics Size 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 customers 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 languages SLOC metrics can be misleading

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

06.03.2014

Dr. S. Nadeem Ahsan, IQRA-University

50

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