1

Emerging Trends in Software Engineering

Prof. R. MallDept. of CSE, IIT, Kharagpur

2

Introduction Technology developments occur:

To adapt to new environments To respond to new challenges

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.

3

Background Software market has two parts:

Products (General purpose software)

Services (custom software) Total business – appx. $1 Trillion

Half in products and half services Services segment is growing fast

4

Background cont…

SE goal is to develop software to satisfy user needs. Either generic or one-off.

Customer needs are considered sacrosanct and fixed: Vendor has to find the solution.

5

Background: A Constraint on Software Engineering

Process

Business Process

Implementation in IT

Time required = T1

Change in Business Process

Change in the IT solution supporting

the business process

Time required = T2

6

Background: Desired Goals

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

Process should efficiently capture requirements of the business and then efficiently convert it to code.

B requires: Implementation should be such that

business process changes can be easily accommodated in the software solution.

7

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.

8

Challenges Being Faced

cont… Software sizes are further increasing.

How software is to be effectively developed in following contexts is not clear: Distributed platforms Working with Internet Distributed development teams

9

Noticeable Software Engineering Technology

Trends Following software engineering trends are easily noticeable: Client-server (or Component-based) development

Service-Oriented Architecture (SOA)

Software as a Service (SaaS)

10

Client-Server Technology

Both clients and servers are pieces of software.

Concepts of Clients and Servers are nothing new --- have existed for ages: Clients are consumers of service. Servers are providers of service.

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

11

Advantages of Client-Server Compared to Traditional

Software Flexibility:

Clients and servers can be easily attached and removed.

Modularity Concurrency Fault-tolerance Clients are cheap computers:

Servers are expensive computers tucked away in some AC rooms.

To use a software you not need not buy expensive server hardware and software.

12

Client-Server versus Traditional Software

The following two factors are possibly the most relevant:

Component-based software development: 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. Current trend of mobile computing:

Handhelds can only be clients due to low processing and memory capabilities.

13

Component Architectures

Two tier architecture: Most obvious

But does not work.

Server 1 Server m

Client 1 Client n

Internet

14

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.

15

Middleware

Solution: 3-tier Architecture

Server 1

Server m

Client 1

Client n

InternetMiddleware

16

Middleware Standards

CORBA versus COM/DCOM CORBA (common object request broker architecture) Being advocated by OMG

COM/DCOM: Being advocated by Microsoft

17

CORBA Architecture

ORB

Server 1 Server m

Skeleton Skeleton

Client 1 Client n

Stub Stub

Object Adapter

DSI DSI

18

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.

19

IDL: Interface Development

Language Interfaces between clients and servers can be specified.

Similar to C++ or Java: But no executable statements.

Interface clock{

set-time(int hh, int mm, int ss);

get-time(int hh, int mm, int ss);

}

20

How to Develop Component-Based

Applications? Divide application into components.

Determine component interfaces: Define using IDL.

Get available components: Build the ones not available

Integrate the components and test

21

CORBA Implementations

VisigenicIonaOrbixJava IDL …

22

COM/DCOM COM used when application runs

on a single machine: DCOM for distributed machine.

Concepts are similar to CORBA: Though terminologies are different. Proxy on client side. More usable than CORBA.

What is a component in COM/DCOM? A .exe or .dll component Created using VB or VC++

23

COM/DCOM versus CORBA

COM/DCOM strong on client side: CORBA on server side. Java Beans an attempt to bridge

this gap. COM/DCOM more usable:

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.

24

Service-Oriented Architecture

(SOA)

25

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.

26

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

27

Service: More Formally

A service is a contractually defined behavior: Implemented and provided by a component for use by an application developer.

28

SOA vs. Component Model

Several things common between services and components: Multiple-use Non-context-specific Composable Encapsulated i.e., non-investigable through its interfaces

A unit of independent deployment and versioning

Loose coupling

29

SOA vs. Component Model

cont…Several things different.Compared to components:

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

Services may be developed and hosted separately. Possibly pay per use.

30

SOA vs. Component Model

cont… Instead of services embedding

calls to each other in their source code: They use defined protocols which

describe how services can talk to each other.

This architecture relies on a business process expert: Links and sequences services, in a

process known as orchestration, to meet a new business requirement.

31

SOA vs. Component Model

cont… SOA targets fairly large chunks of

functionality to be strung together to form new services: Built almost entirely from existing

software services. The larger the chunks:

The fewer the interfacings required; Faster development; However, very large chunks may

not prove easy to reuse.

32

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.

33

SOA : Nitty Gritty cont…

A paradigm for utilizing distributed capabilities: May be under the control of different ownership domains.

Provides a uniform means: To offer, discover, interact with and use capabilities to achieve desired results.

34

SOA: Nitty Gritty cont…

SOA would fundamentally change the way we construct software systems. SOA involves statically and

dynamically plugging-in services to build software.

SOA players: BEA Aqua logic, Oracle Web services

manager, HP Systinet Registry, MS .Net, IBM Web Sphere, Iona Artrix, Java composite application suite.

35

SOA: Nitty Gritty cont…

Views software as providing a set of services: 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

An app can be built using these services: And building the “missing” ones.

36

Principles of Service-Orientation: Services

Services: Abstract the underlying data and logic

Composable Autonomous Share a formal contract Loosely coupled Stateless Discoverable

37

Service Consumer

Service Provider

Contract Registry

SOA Entities

38

SOA Implementation Web services can implement a service-oriented architecture.

Web services make functional building blocks Accessible over standard Internet protocols

Independent of platforms and programming languages.

39

Service Orchestration

Requires metadata in sufficient detail to describe: The characteristics of the services, Also the data that drives them.

The services are typically described by WSDL.

Communications protocols by SOAP.

Data and meta data by XML

40

SOA Vision Have a marketplace for services: It will automatically improve quality and reduce prices.

To build an application: Use off-the-shelf services and possibly build some.

Cost of building reduces; Also cost of ownership (which is quite large for regular software) reduces.

41

Great Promise of SOA

The cost of creating the n-th application is near-zero, As all of the software services required already exists.

Only orchestration required to produce a new application.

42

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

43

Software as a Service (SaaS)

44

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.

45

Background To have water supply at home:

Do you install system to pump water from river directly to your home?

To get electricity supply: Do you install a thermal or hydro

electric generator? It would lead to wastage:

You do not need to have all the water pipes open all the time.

Unnecessarily expensive proposition.

46

Background cont…

Should you own Rational Suite paying Rs. 50 Lakhs: If 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.

47

SaaS Lets customers pay for what they need and when: With price reflecting market place supply and demand.

SaaS includes: Elements of outsourcing and Application service provisioning

48

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.

49

SaaS vs. SOA SaaS is a software delivery model: SOA is a software construction model.

SaaS counters the concept of a user as the owner: Owner is a vendor who hosts the software and lets the users execute on-demand charges per usage units.

50

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.

51

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.

52

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. Target the "long tail" of small customers

53

Current Business Model

54

SaaS Business Model

55

SaaS Architecture…

Meta-Model

Data

Player

Designer

Application Instance

Play/Edit

Edit

Client 1

Client 2

Client n

56

Summary Some of the basic assumptions of

software are changing This is leading to some different

paradigms for software delivery. Component-based development:

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.