Emerging Trends in Software Engineering

Dept. of CSE, IIT, Kharagpur

Prof. R. Mall

Technology developments occur:

Introduction

Few important developments that have occurred over the last decade or so:
Desktops have become more powerful and at the same time more affordable. Internet has become widely accepted. Mobile computing. Outsourcing has become prevalent.

To adapt to new environments To respond to new challenges

Background

Software market has two parts:

Products

Total business appx. $1 Trillion

Half

(General purpose software) Services (custom software)

in products and half services Services segment is growing fast

Background

SE goal is to develop software to satisfy user needs.

Either

cont

generic or one-off.

Customer needs are considered sacrosanct and fixed:

Vendor

has to find the solution.

4

Background: A Constraint on Software Engineering Process

Business Process
Time required = T1
Implementation in IT Change in Business Process

Time required = T2
Change in the IT solution supporting the business process

Background: Desired Goals

A. Reduce T1 (and improve quality) B. Reduce T2

A requires:

B requires:

Process should efficiently capture requirements of the business and then efficiently convert it to code. Implementation should be such that business process changes can be easily accommodated in the software solution.
6

Challenges Being Faced

Delivery time requirements are shortening:

High business velocity requires this.

Software is becoming a bottleneck in implementing business process changes.

Businesses are getting tired of software cost, late deliveries, poor quality, risk,

Hardware and software cost differentials are becoming more and more glaring.
7

Challenges Being Faced

Software sizes are further increasing. How software is to be effectively developed in following contexts is not clear:
Distributed

cont

platforms Working with Internet Distributed development teams

Noticeable Software Engineering Technology Trends

Following software engineering trends are easily noticeable:

Client-server

development (SOA)

(or Component-based) Architecture

Service-Oriented Software

as a Service (SaaS)
9

Client-Server Technology

Both clients and servers are pieces of software. Concepts of Clients and Servers are nothing new --- have existed for ages:

Why is then a sudden interest seen in client-server software architecture?

10

Clients are consumers of service. Servers are providers of service.

Advantages of Client-Server Compared to Traditional Software

Flexibility:

Modularity Concurrency Fault-tolerance Clients are cheap computers:

Clients and servers can be easily attached and removed.

Servers are expensive computers tucked away in some AC rooms. To use a software you not need not buy expensive server hardware and software.
11

Client-Server versus Traditional Software

The following two factors are possibly the most relevant: Component-based software development:

Current trend of mobile computing:

To develop a hardware solution an electronic engineer does not solder transistors and resistors on a PCB --- uses off-the-shelf ICs. Why not do the same for software.
Handhelds can only be clients due to low processing and memory capabilities.
12

Component Architectures

Two tier architecture: Most obvious

Server 1 Server m

Internet
Client 1 Client n

But does not work.

13

What are the Problems with the 2-tier Architecture?

Servers can be bottleneck. How to locate servers? Client-Server incompatibility:

Analogy:

House hunting in Bangalore.

14

Solution: 3-tier Architecture

Server 1 Middleware Middleware
Client 1

Server m

Internet
Client n

15

Middleware Standards

CORBA versus COM/DCOM CORBA (common object request broker architecture)

Being

advocated by OMG advocated by Microsoft

16

COM/DCOM:
Being

CORBA Architecture
Server 1

Skeleton DSI

Skeleton DSI

Server m

ORB
Stub
Client 1

Object Adapter Stub

Client n
17

CORBA Architecture

Skeleton:

Marshalls client requests

The servers register themselves with the object-adapter. The ORB delivers the client request to the server. The Skeleton marshalls the server response. DII/DSI for dynamic service invocation.
18

IDL: Interface Development Language

Interfaces between clients and servers can be specified. Similar to C++ or Java:

But

no executable statements.
set-time(int hh, int mm, int ss); get-time(int hh, int mm, int ss);

Interface clock{

}
19

How to Develop ComponentBased Applications?

Divide application into components. Determine component interfaces:

Define

using IDL.

Get available components:

Build

the ones not available

Integrate the components and test

20

CORBA Implementations

Visigenic Iona Orbix Java IDL

21

COM used when application runs on a single machine:

COM/DCOM

Concepts are similar to CORBA:

DCOM for distributed machine.

What is a component in COM/DCOM?

A .exe or .dll component Created using VB or VC++

Though terminologies are different. Proxy on client side. More usable than CORBA.

22

COM/DCOM versus CORBA

COM/DCOM strong on client side:

COM/DCOM more usable:

CORBA on server side. Java Beans an attempt to bridge this gap. If your application is to run only on Microsoft operating systems, better use COM/DCOM. If your application needs to run on heterogeneous platforms, better use CORBA. 23

Service-Oriented Architecture (SOA)

24

SOA: Introduction

Service-orientation principles have their roots in the object-oriented designing. Many claim that service-orientation will replace object-orientation:
Others

think the two are complementary paradigms.

25

What is SOA?

Build applications by composing software services. What is a software service?

Essentially software components. Typically implement functionality most humans would recognize as a service.

Examples of services:

Filling out an online application Viewing an online bank-statement Placing an online booking
26

Service: More Formally

A service is a contractually defined behavior:

Implemented

and provided by a component for use by an application developer.

27

SOA vs. Component Model

Several things common between services and components:

Multiple-use Composable Non-context-specific Encapsulated

i.e., non-investigable through its interfaces A unit of independent deployment and versioning Loose coupling

28

SOA vs. Component Model

Several things different. Compared to components:

cont

SOA's

atomic-level objects are often 100 to 1,000 times larger.

Services may be developed and hosted separately.

Possibly

pay per use.

29

SOA vs. Component Model

cont

Instead of services embedding calls to each other in their source code:

This architecture relies on a business process expert:

They use defined protocols which describe how services can talk to each other.

Links and sequences services, in a process known as orchestration, to meet a new business requirement.
30

SOA vs. Component Model

cont

SOA targets fairly large chunks of functionality to be strung together to form new services:

The larger the chunks:

Built almost entirely from existing software services.

The fewer the interfacings required; Faster development; However, very large chunks may not prove easy to reuse.
31

SOA: Nitty Gritty

SOA is a collection of services:

That

communicate with each other.

The services are self-contained:

Do

not depend on the context or state of the other service.

Each service works within a distributed-system architecture.

32

SOA : Nitty Gritty

cont

A paradigm for utilizing distributed capabilities:

May

be under the control different ownership domains.

of

Provides a uniform means:

To

offer, discover, interact with and use capabilities to achieve desired results.
33

SOA: Nitty Gritty

SOA would fundamentally change the way we construct software systems.

cont

SOA involves statically and dynamically plugging-in services to build software. BEA Aqua logic, Oracle Web services manager, HP Systinet Registry, MS .Net, IBM Web Sphere, Iona Artrix, Java composite application suite.
34

SOA players:

SOA: Nitty Gritty

Views software as providing a set of services:

cont

Each service composed of smaller services.

Leverages the Internet and emerging standardization on it for interoperability Hopes that a market place for different predefined services can emerge:

Not tied to any specific vendor And building the missing ones.
35

An app can be built using these services:

Services:

Principles of ServiceOrientation: Services

the underlying data and

Abstract

logic Composable Autonomous Share a formal contract Loosely coupled Stateless Discoverable

36

SOA Entities
Service Consumer

Contract

Registry

Service Provider

37

SOA Implementation
Web services can implement a service-oriented architecture. Web services make functional building blocks

Accessible

protocols Independent of platforms and programming languages.

over standard Internet

38

Service Orchestration

Requires metadata in sufficient detail to describe: The services are typically described by WSDL. Communications protocols by SOAP. Data and meta data by XML
39

The characteristics of the services, Also the data that drives them.

Have a marketplace for services:

It

SOA Vision

will automatically improve quality and reduce prices.

Use off-the-shelf services and possibly build some. cost of ownership (which is quite large for regular software) reduces.

To build an application:

Cost of building reduces;

Also
40

Great Promise of SOA

The cost of creating the n-th application is near-zero,

As

all of the software services required already exists. orchestration required to produce a new application.
41

Only

SOA Challenges

Building services and infrastructure Composing services formal theory and algebra, languages, semantics Testing and verification Trust Non Functional properties Changes Business level modeling and translation Developing the marketplace
42

Software as a Service (SaaS)

43

Challenge Faced

Owning software is very expensive:

An Rs. 50 Lakh software running on an Rs. 1 Lakh computer is common place.

As with hardware, owning software is the business tradition:

Both products and services bought and used.

Most of IT budget now goes in supporting the software assets.

44

Background

To have water supply at home:

Do you install system to pump water from river directly to your home? Do you install a thermal or hydro electric generator? You do not need to have all the water pipes open all the time. Unnecessarily expensive proposition.
45

To get electricity supply:

It would lead to wastage:

Background

Should you own Rational Suite paying Rs. 50 Lakhs:

If

cont

you use it only 10 hours every month One hour of usage costs Rs. 100/ Also frees use from maintenance and data storage costs --- Given that maintenance is usually a severe overhead.
46

Lets customers pay for what they need and when:

With

SaaS

price reflecting market place supply and demand. of outsourcing and service provisioning
47

SaaS includes:
Elements Application

SaaS

SaaS is a model of software delivery:

Software

owner provides maintenance, daily technical operation, and support for the software. Services are provided to the clients on amount of usage basis.
48

SaaS vs. SOA

SaaS is a software delivery model:

SOA

SaaS counters the concept of a user as the owner:

Owner

is a software construction model.

is a vendor who hosts the software and lets the users execute on-demand charges per usage units.
49

SaaS versus SOA

Despite significant differences:

Espouse closely related architecture models.

SaaS and SOA complement each other:

SaaS helps to offer components for SOA to use. SOA helps to help quickly realize SaaS.

Main enabler of SaaS and SOA:

Internet and web services technologies.

50

Key Characteristics

Network-based access and management of commercially available (not custom) software. Activities managed from central location and not at customer site,

Enabling customers to access applications remotely via the Web.

Application delivery follows a one-to-many model (single instance, multi-tenant architecture):

In contrast to a one-to-one model.

51

Business Model

Shift "ownership" of the software:

From the customer to a service provider.

Shift responsibility for hardware and software management:

From the customer to the provider

Reduce the cost of providing software services:

Through specialization and economy of scale. 52 Target the "long tail" of small customers

Current Business Model

53

SaaS Business Model

54

SaaS Architecture
Client 1 Meta-Model

Application Instance

Client 2

Play/Edit Player

Client n Edit Data

Designer

55

Some of the basic assumptions of software are changing This is leading to some different paradigms for software delivery. Component-based development:

Summary

Expected to reduce development time, cost and at the same time improve quality.

SaaS is changing the way software is delivered.

SOA conceives a component based assembly model with independent component vendors.56