+ All Categories
Home > Documents > CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932...

CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932...

Date post: 03-Jan-2016
Category:
Upload: louise-byrd
View: 217 times
Download: 2 times
Share this document with a friend
Popular Tags:
39
CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 [email protected] www.sice.umkc.edu/~leeyu
Transcript
Page 1: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

CS551 - Lecture 21

CS551Advanced Software Engineering

Yugi Lee

STB #555(816) 235-5932

[email protected]

www.sice.umkc.edu/~leeyu

Page 2: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

2CS551 - Lecture 2

Today’s Software Development

• Development of large & complex systems

• Software systems must fulfill the requirements of stakeholders (clients, end-users, developers,…)

• Many people involved in the development

• Software systems are expected to live long and be used by many people

• Evolving technologies and computing environment

Page 3: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

3CS551 - Lecture 2

The Software Crisis/Solution

• 1968: NATO conference in Garmisch-Partenkirchen– Software crisis (to characterize the situation)

• Increased quality demands on software products

• High cost and time pressure

• Shorter time to market

• Coordination problems within the projects

• Scarce resources

– Software engineering (idea for a solution)

Page 4: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

4CS551 - Lecture 2

What’s Software Crisis?

Unacceptably low quality of software

Delayed deadlines: Average 1 year

Over cost limits: Average 2X estimate

E.g. Air Force Command and Control system

Initial estimate $1.5million Winner’s bid $0.4 million Actual cost $3.7 million

After deliver?

E.g. U.S Army study of Federal projects Delivered, but not used

47%Paid for, but not delivered

29%Abandoned or reworked

19%Used after changes 3%

Used as delivered 2%

Page 5: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

5CS551 - Lecture 2

Example: Practical Disasters

• European Space Agency Ariane 5– Track control system failure results in self destruction

• Denver Airport– Late delivery of software for the baggage system delays the

opening of the airport by 16 months • US study (1995): 81 billion US$ spend per year for

failing software development projects

Page 6: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

6CS551 - Lecture 2

Why & What Software Engineering?

• Why? ...to get away from ad hoc and unpredictable software development towards a systematic, understood one...

• What? The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software [IEEE-93]

Page 7: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

7CS551 - Lecture 2

Three P’s

Processes Products

People

Planning, coordination, management, measuring, Analyzing, designing, coding, .....

Requirements, design, source code, executable, user documentation, test cases, test results, change request ....

Education, skills, communicationStyle .....

Page 8: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

8CS551 - Lecture 2

Why still Software Engineering?

Has the software crisis vanished? No!

• Software projects still run over time and out of budget

• no break through in quality !!![still art instead of engineering discipline]

Why is Software so Hard? – Software is [Parnas, 1985]: Buggy, Unreliable,

Forever changing, Unwarrantable

Page 9: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

9CS551 - Lecture 2

What is a Distributed System?

• A collection of autonomous hosts that that are connected through a computer network.

• Each host executes components and operates a distribution middleware

• Middleware enables the components to coordinate their activities

• Users perceive the system as a single, integrated computing facility.

Page 10: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

10CS551 - Lecture 2

Hostn-1

Hostn

Host2

Host1

What is a Distributed System?What is a Distributed System?

MiddlewareMiddleware

MiddlewareMiddleware

Network Operating SystemNetwork Operating System

Network Operating SystemNetwork Operating System

HardwareHardware

HardwareHardware

Component1 Componentn

Component1 Componentn

Component1 Componentn

Component1 Componentn

Network

Page 11: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

11CS551 - Lecture 2

Component-Based Software Engineering?

• An emerging concept called "a component-based software" appears to be a solution for the development of software system.

• The component-based software engineering focuses on the entities (objects) developed and the components intended from their inception to be used within a framework in which they are placed in containers and combined with other components.

Page 12: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

12CS551 - Lecture 2

Middleware ExamplesMiddleware Examples

• Transaction-oriented– IBM CICS

– BEA Tuxedo

– IBM Encina

– Microsoft Transaction Server

• Message-oriented– Microsoft Message Queue

– NCR TopEnd

– Sun Tooltalk

• Transaction-oriented– IBM CICS

– BEA Tuxedo

– IBM Encina

– Microsoft Transaction Server

• Message-oriented– Microsoft Message Queue

– NCR TopEnd

– Sun Tooltalk

• Procedural– Sun ONC

– Linux RPCs

– OSF DCE

• Object-oriented– OMG CORBA

– Sun Java/RMI

– Microsoft COM

– Sun Enterprise Java Beans

• Procedural– Sun ONC

– Linux RPCs

– OSF DCE

• Object-oriented– OMG CORBA

– Sun Java/RMI

– Microsoft COM

– Sun Enterprise Java Beans

Page 13: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

13CS551 - Lecture 2

Centralized vs. Distributed System

• One component with non-autonomous parts

• Component shared by users all the time

• All resources accessible• Software runs in a single

process• Single Point of control• Single Point of failure

• Multiple autonomous components

• Components are not shared by all users

• Resources may not be accessible

• Software runs in concurrent processes on different processors

• Multiple Points of control/failure

Page 14: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

14CS551 - Lecture 2

Real World Example: Hong Kong TelecomReal World Example: Hong Kong Telecom

• Video-on-demand: provide subscribers with facilities to download videos from HK TK servers to low-cost Web-TVs.

• currently 90,000 users.

• Built using distributed object-technology.

• Video-on-demand: provide subscribers with facilities to download videos from HK TK servers to low-cost Web-TVs.

• currently 90,000 users.

• Built using distributed object-technology.

Page 15: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

15CS551 - Lecture 2

Requirements

• Hardware:

– Clients: Web-TV

– Servers: RISC processor

• Operating System Heterogeneity :

– Clients: Java OS

– Servers: UNIX

• Programming Language Heterogeneity:

– Clients: Java

– Servers: C++

• Communication across Network

– How to transmit complex data structures across the Internet?

• Scale

– Scaling from initially several hundred to currently 90,000 users

• Security

– Secure Payment

– Authentication

Page 16: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

16CS551 - Lecture 2

Why Distributed Object Technology?

• Distributed:– Video clients need to download/show video on customer’s Web-

TV

– Multiple servers needs to be operated by Hongkong Telecom

• Object Technology:– Video clients are written in Java:

• Web-TV has Java Virtual Machine

• portability to e.g. Sony Playstation, Sega-Console...

– Video servers are written in C++:

• high performance

Page 17: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

17CS551 - Lecture 2

TradingWorkstation

TradingWorkstation

AuthorisationServices

AuthorisationServices

Host ServicesHost Services

Customer Information

Services

Customer Information

Services

Product DatabaseServices

Product DatabaseServices

MarketingServices

MarketingServices

Another Example:IT Infrastructure of UBS

Page 18: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

18CS551 - Lecture 2

Requirements

• Time to market

– Development of new applications with recent technology

– Integration of new applications increasingly difficult

• Scalability

– Management of 30,000,000 accounts

– Management of 10,000,000 customers

– Use by 2,000 concurrent users

• Reliability

• Hardware Heterogeneity– Unisys Mainframes– IBM Mainframes– SPARC Servers– PC Workstations

• Operating System Heterogeneity– MVS– UNIX– Win-NT

• Programming Language Heterogeneity– Cobol– C/C++– Visual Basic

Page 19: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

19CS551 - Lecture 2

Why Distributed Object Technology?

• Uniform view of all banking services• Appropriate level of abstraction• Preserving investment by wrapping legacy applications• Exploiting advantages of object technology for new

development• Resolving

– distribution– heterogeneity

Page 20: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

20CS551 - Lecture 2

Boeing 777 Configuration Mgmnt.

Page 21: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

21CS551 - Lecture 2

Requirements

• Scale– 3,000,000 parts per aircraft– Configuration of every aircraft is different– CAA regulations demand that records are kept for every

single part of aircraft– Aircraft evolve during maintenance– Boeing produce 500 aircraft per year– Configuration database grows by 1.5 billion parts each year– Projected life of each aircraft 30 years– 45,000 engineers need on-line access to engineering data

Page 22: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

22CS551 - Lecture 2

Requirements

• COTS Integration– Existing IT infrastructure was no longer appropriate

– Boeing could not afford to build required IT infrastructure from scratch

– Components were purchased from several different specialized vendors

• relational database technology

• enterprise resource planning

• computer aided project planning

– Components needed to be integrated

Page 23: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

23CS551 - Lecture 2

Requirements

• Heterogeneity– 20 Sequent database machines as servers for the

engineering data– 200 UNIX application servers– NT and UNIX workstations for engineers

Page 24: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

24CS551 - Lecture 2

Why Distributed Object Technology

• Object wrapping of COTS

• Resolution of distribution at high level of

abstraction

• Resolution of heterogeneity

• Scalability

Page 25: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

25CS551 - Lecture 2

A Brief History of ObjectsA Brief History of ObjectsTime

RDF

DARM + OIL

WSDL

UDDIPeer-to-PeerGRID

Simula-67Information Hiding

LanguagesDistributed Systems Software Engineering1970

2000

XML

Smalltalk

C++Eiffel

Java

CORBACOM

OOAD

UML

Sun ONC

DCE

1980

1990

DCOM

HTML

SOAP

Page 26: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

26CS551 - Lecture 2

Distributed System Requirements

• Integration of new, legacy and components off-the-shelf– Legacy components might not need to be re-engineered– COTS cannot be modified

• Heterogeneity of– hardware platforms– operating systems– networks– programming languages

• Construction of distributed systems

Page 27: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

27CS551 - Lecture 2

Distributed System Requirements

• What are we trying to achieve when we construct a distributed system?

• Certain requirements are common to many distributed systems– Resource Sharing

– Openness

– Concurrency

– Scalability

– Fault Tolerance

– Transparency

Page 28: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

28CS551 - Lecture 2

Resource SharingResource Sharing

• Ability to use any hardware, software or data anywhere in the system.

• Resource manager controls access, provides naming scheme and controls concurrency.

• Resource sharing model (e.g. client/ server or object-based) describing how – resources are provided, – they are used and – provider and user interact with each other.

• Ability to use any hardware, software or data anywhere in the system.

• Resource manager controls access, provides naming scheme and controls concurrency.

• Resource sharing model (e.g. client/ server or object-based) describing how – resources are provided, – they are used and – provider and user interact with each other.

Page 29: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

29CS551 - Lecture 2

OpennessOpenness

• Openness is concerned with extensions and improvements of distributed systems.

• Detailed interfaces of components need to be published.

• New components have to be integrated with existing components.

• Differences in data representation of interface types on different processors (of different vendors) have to be resolved.

• Openness is concerned with extensions and improvements of distributed systems.

• Detailed interfaces of components need to be published.

• New components have to be integrated with existing components.

• Differences in data representation of interface types on different processors (of different vendors) have to be resolved.

Page 30: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

30CS551 - Lecture 2

ConcurrencyConcurrency

• Components in distributed systems are executed in concurrent processes.

• Components access and update shared resources (e.g. variables, databases, device drivers).

• Integrity of the system may be violated if concurrent updates are not coordinated.– Lost updates– Inconsistent analysis

• Components in distributed systems are executed in concurrent processes.

• Components access and update shared resources (e.g. variables, databases, device drivers).

• Integrity of the system may be violated if concurrent updates are not coordinated.– Lost updates– Inconsistent analysis

Page 31: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

31CS551 - Lecture 2

ScalabilityScalability

• Adoption of distributed systems to– accommodate more users– respond faster (this is the hard one)

• Usually done by adding more and/or faster processors.

• Components should not need to be changed when scale of a system increases.

• Design components to be scalable!

• Adoption of distributed systems to– accommodate more users– respond faster (this is the hard one)

• Usually done by adding more and/or faster processors.

• Components should not need to be changed when scale of a system increases.

• Design components to be scalable!

Page 32: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

32CS551 - Lecture 2

Fault ToleranceFault Tolerance

• Hardware, software and networks fail!

• Distributed systems must maintain availability even at low levels of hardware/software/network reliability.

• Fault tolerance is achieved by – recovery– redundancy

• Hardware, software and networks fail!

• Distributed systems must maintain availability even at low levels of hardware/software/network reliability.

• Fault tolerance is achieved by – recovery– redundancy

Page 33: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

33CS551 - Lecture 2

TransparencyTransparency

• Distributed systems should be perceived by users and application programmers as a whole rather than as a collection of cooperating components.

• Transparency has different dimensions that were identified by ANSA.

• These represent various properties that distributed systems should have.

• Distributed systems should be perceived by users and application programmers as a whole rather than as a collection of cooperating components.

• Transparency has different dimensions that were identified by ANSA.

• These represent various properties that distributed systems should have.

Page 34: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

34CS551 - Lecture 2

Access Transparency

Access Transparency

LocationTransparency

LocationTransparency

ConcurrencyTransparencyConcurrencyTransparency

Migration Transparency

Migration Transparency

Performance TransparencyPerformance Transparency

Scalability Transparency

Scalability Transparency

Replication TransparencyReplication

Transparency

FailureTransparency

FailureTransparency

Distribution TransparencyDistribution Transparency

Page 35: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

35CS551 - Lecture 2

Access/Location TransparencyAccess/Location Transparency

• Access Transparency– Enables local and remote information objects to be

accessed using identical operations.– E.g: File system operations in NFS, Navigation in the

Web, SQL Queries

• Location Transparency– Enables information objects to be accessed without

knowledge of their location.– E.g: File system operations in NFS, Pages in the Web,

Tables in distributed databases

• Access Transparency– Enables local and remote information objects to be

accessed using identical operations.– E.g: File system operations in NFS, Navigation in the

Web, SQL Queries

• Location Transparency– Enables information objects to be accessed without

knowledge of their location.– E.g: File system operations in NFS, Pages in the Web,

Tables in distributed databases

Page 36: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

36CS551 - Lecture 2

Concurrency/Replication TransparencyConcurrency/Replication Transparency

• Concurrency Transparency– Enables several processes to operate concurrently using

shared information objects without interference between them.

– e.g, NFS, Automatic teller machine network, Database management system

• Replication Transparency – Enables multiple instances of information objects to be used

to increase reliability and performance without knowledge of the replicas by users or application programs

– e.g, Distributed DBMS, Mirroring Web Pages.

• Concurrency Transparency– Enables several processes to operate concurrently using

shared information objects without interference between them.

– e.g, NFS, Automatic teller machine network, Database management system

• Replication Transparency – Enables multiple instances of information objects to be used

to increase reliability and performance without knowledge of the replicas by users or application programs

– e.g, Distributed DBMS, Mirroring Web Pages.

Page 37: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

37CS551 - Lecture 2

Failure/Migration TransparencyFailure/Migration Transparency

• Failure Transparency– Enables the concealment of faults– Allows users and applications to complete their tasks

despite the failure of other components. e.g. Database Management System

• Migration Transparency– Allows the movement of information objects within a

system without affecting the operations of users or application programs. e.g., NFS, Web Pages

• Failure Transparency– Enables the concealment of faults– Allows users and applications to complete their tasks

despite the failure of other components. e.g. Database Management System

• Migration Transparency– Allows the movement of information objects within a

system without affecting the operations of users or application programs. e.g., NFS, Web Pages

Page 38: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

38CS551 - Lecture 2

Scaling/Performance TransparencyScaling/Performance Transparency

• Performance Transparency– Allows the system to be reconfigured to improve

performance as loads vary. – E.g. Distributed make.

• Scaling Transparency– Allows the system and applications to expand in scale

without change to the system structure or the application algorithms.

– E.g.,World-Wide-Web, Distributed Database

• Performance Transparency– Allows the system to be reconfigured to improve

performance as loads vary. – E.g. Distributed make.

• Scaling Transparency– Allows the system and applications to expand in scale

without change to the system structure or the application algorithms.

– E.g.,World-Wide-Web, Distributed Database

Page 39: CS551 - Lecture 2 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

39CS551 - Lecture 2

Key PointsKey Points

• What is a Distributed Systems

• Adoption of Distributed Systems is driven by Non-Functional Requirements

• Distribution needs to be transparent to users and application designers

• Transparency has several dimensions

• Transparency dimensions depend on each other

• What is a Distributed Systems

• Adoption of Distributed Systems is driven by Non-Functional Requirements

• Distribution needs to be transparent to users and application designers

• Transparency has several dimensions

• Transparency dimensions depend on each other


Recommended