CS551 Advanced Software Engineering

1
CS551Advanced Software Engineering

• Yugi Lee
• STB 555
• [phone]
• leeyu_at_umkc.edu
• www.sice.umkc.edu/leeyu

2
Todays 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

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

4
Whats 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
• Winners 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

5
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

6
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

7
Three Ps
Education, skills, communication Style .....
People
Processes
Products
Requirements, design, source code, executable,
user documentation, test cases, test results,
change request ....
Planning, coordination, management, measuring,
Analyzing, designing, coding, .....
8
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

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

10
What is a Distributed System?
11
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.

12
Middleware Examples

• 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

13
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

14
Real 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.

15
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

16
Why Distributed Object Technology?

• Distributed
• Video clients need to download/show video on
  customers 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

17
Another ExampleIT Infrastructure of UBS
Customer Information Services
Authorisation Services
Trading Workstation
Product Database Services
Marketing Services
Host Services
18
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

19
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

20
Boeing 777 Configuration Mgmnt.
21
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

22
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

23
Requirements

• Heterogeneity
• 20 Sequent database machines as servers for the
  engineering data
• 200 UNIX application servers
• NT and UNIX workstations for engineers

24
Why Distributed Object Technology

• Object wrapping of COTS
• Resolution of distribution at high level of
  abstraction
• Resolution of heterogeneity
• Scalability

25
A Brief History of Objects
Time
DARM OIL
GRID
RDF
WSDL
Peer-to-Peer
UDDI
2000
XML
Java
DCOM
UML
SOAP
COM
1990
CORBA
OOAD
HTML
Eiffel
DCE
C
1980
Sun ONC
Smalltalk
Information Hiding
1970
Simula-67
Distributed Systems
Software Engineering
Languages
26
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

27
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

28
Resource 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.

29
Openness

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

30
Concurrency

• 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

31
Scalability

• 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!

32
Fault 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

33
Transparency

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

34
Distribution Transparency
Concurrency Transparency
Access Transparency
Location Transparency
35
Access/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

36
Concurrency/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.

37
Failure/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

38
Scaling/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

39
Key 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