Software Engineering Lecture 22: Client-Server Software Engineering.

30
Software Engineering Lecture 22: Client-Server Software Engineering

Transcript of Software Engineering Lecture 22: Client-Server Software Engineering.

Software Engineering

Lecture 22: Client-Server Software Engineering

Today’s Topics Basic Principles of C/S Systems Configurations, Subsystem Linking Object Request Broker (ORB) SE Paradigms for C/S Systems Testing C/S Systems

Client-Server SE “A dominant architecture for information

processing” Collective result of many improvements in

computing:• Network bandwidth

• Database technology

• Internet & WWW

What are the related SE issues?

Basic Elements Root System

• Mainframe or DB server

• Repository for corporate data

Servers• Update & request corporate data

• Implement departmental systems

Network• Connectivity via LAN, WAN, Internet

Clients (individual PCs)

Generic Client-Server Architecture

[From SEPA 5/e]

Client-Server Options

[From SEPA 5/e]

• File Servers file request / data response• Database Servers SQL request / table response• Transaction Servers remote procedure request• Groupware Servers client connectivity

C/S Software Components “Several distinct subsystems that can be allocated

to client or server” “Distributed among machines”

multi-tier, networked architecture

Components [2] Classic 3-tier architecture:

• User interaction/presentation subsystem

• Application subsystem

• Database management subsystem

WebBrowser

WebServer

DBServer

JavaServlet

Client 1 Server 1 Server 2

Web Example

Middleware Software components that exist on both client &

server:• Networking (e.g., TCP/IP)

• Application Connectivity(e.g. HTTP, CORBA)

“The nervous system of a client-server system” [Orfali, et al. ’99]

Distributing Functionality Fat Server design

most functionality on the server e.g., file server, DB server

Fat Client design most functionality on the client e.g., message forwarding system

Distributed Presentationclient handles display only

Remote Presentationclient prepares display from data

Distributed Logicclient handles data entry & update

Remote Data Managementclient processes data (e.g. DSS)

Distributed Databasesclient manages data

Distributed Configurations

Guidelines Presentation on the client

• Windows/PC-based

• Offload GUI processing to client

Shared DBs on a server• DBMS, physical database

Static / frequently-used data stored on the client• Minimize unnecessary network traffic

Linking C/S Subsystems Pipes (Unix-based)

• One process can share data with another (across machines, OS)

Remote Procedure Call (RPC)• One process can invoke another (across machines, OS)

Client/Server SQL• A process can query / update data from a central RDBMS

Web Linking Hypertext Transfer Protocal (HTTP)

• Web browser can retrieve data (HTML) from a web server

Common Gateway Interface (CGI)• Web browser can invoke a process (script, servlet, etc.) on a

web server

Object Request Broker Middleware Coordinates message-passing between client and

server objects• Finds location of server object(s)

• Invokes method(s)

• Returns resulting data to client

Examples: COM, CORBA, EJB

ORB Client/Server Connectivity

Stubs give a client ageneric way of requestingservices, regardless of howthe client is implemented

Skeletons give a server ageneric way to provideservices, regardless ofhow they are implemented

[Vogel & Duddy, ’98]

CORBA Architecture [Orfali & Harkey ’98]

CORBAArchitecture

[From SEPA 5/e]

• IDL: Interface Description Language (objects, attributes, & methods)

• IDL stubs act as a gateway for C/S communication

• Object implementations are hidden, can vary (Java, C++, etc.)

SE Paradigms for C/S SystemsMany are possible, two are common:

Evolutionary Paradigm• Event-based and/or object-based

Component-Based Paradigm• COTS & in-house components

Or, some hybrid of both…

Analysis Modeling Constraints of the design & implementation can

influence analysis phasee.g., qualification step from CBSEe.g., architectural constraints

Design Phase Data & architectural design dominate the process Behavioral modeling important for event-driven

systems User interface design a key activity for client side Object-oriented approach is usually the most

appropriate

Architectural Design Key criterion: scalability Synchronous vs. asynchronous communication ORB architecture can be used as an adaptive

infrastructure for integrating multiple COTS modules

Sharing Data with the Client Manual extract

User initiates a static, local copy Snapshot

Automatic extraction of local copy Replication

Fully-coordinated, real-time duplication Fragmentation

Distributed storage of virtual DB

Designing a C/S Business Process [Porter ’95]

Identify files created, updated, referenced, deleted Define components or objects For each component, define business rules &

information Decompose rules down to methods Define additional components necessary to

support the methods

Structure ChartNotation [Porter ‘95]

[From SEPA 5/e]

Testing Issues Distributed software is difficult to test!

• Client GUI

• Environment / platform diversity

• Networked databases

• Distributed processing

• Non-robust target environment

• Non-linear performance relationships

Testing Phases Clients tested in isolation Client & server tested in isolation

(test or dummy networking) Complete architecture is tested

(including network & real-time performance)

Typesof Tests

Application function testsclient functionality, standalone

Server testsresponse time, throughput

Database testsaccuracy, integrity, archiving

Transaction testscorrectness, performance

Network communication testsconnectivity, traffic, security

Operational Profile Common usage patterns

• Vary per user, time period, task, etc.

• Based on user scenarios

Abnormal usage patterns• Average- vs. worst-case performance

• Malicious attacks (web systems)

Global Expectations• maximum acceptable downtime, delay, etc.

Questions?