1 / 11

System interfaces

Asper School of Business University of Manitoba. Systems Analysis & Design. Instructor: Bob Travica. System interfaces. Updated: November 2013. Outline. System interface concept Electronic Data Interchange eXtensible Markup Language Rules for system inputs Rules for system outputs.

jensen
Download Presentation

System interfaces

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica System interfaces Updated: November 2013

  2. Outline • System interface concept • Electronic Data Interchange • eXtensible Markup Language • Rules for system inputs • Rules for system outputs 3510 Systems Analysis & Design * Bob Travica

  3. Note: In contrast to book, reports are part of user interface (see slides for the previous class). System interface concept • 1) Interface with no or minimal participation of users AND • 2) Destination is another system, not user (System-to-system connection; Inputs & outputs exchanged b/w systems).* • Examples: • Inputs from other systems & external databases • Automated inputs (e.g., bar code reader) • Outputs to other systems & external databases 3510 Systems Analysis & Design * Bob Travica

  4. Technologies for system interfaces- Electronic Data Interchange • Electronic data interchange (EDI) input/output files (More...) • Automatically formatted text files that represent business documents • Since 1960s • Auto industry big user • Can link to electronic funds transfer (EFT) • Both sender and receiver must use same EDI system. Was complex, expensive; cheaper Internet-based solutions today. 3510 Systems Analysis & Design * Bob Travica

  5. eXtensible Markup Language • eXtensible Markup Language (XML) input/output files • Text files with embedded markup that describes content • Since late 1990s • Sender and receiver share definition of content (Data Type Definition) • Simple, cheap • Security issues 3510 Systems Analysis & Design * Bob Travica

  6. XML example 3510 Systems Analysis & Design * Bob Travica

  7. Identifying system interfaces • System Sequence Diagram can indicate system interfaces 3510 Systems Analysis & Design * Bob Travica

  8. Rules for system inputs • 1. Must come from a trusted source • 2. Be secure (encryption) • 3. Be validated for accuracy (values’ range, data • type, completeness, algorithms) • 4. Capture data close to the source • 5. Use automatic entry and avoid human involvement as much as possible • electronic input rather than manual reentering of data (e.g., bar-code scanner, radio frequency identifier) 3510 Systems Analysis & Design * Bob Travica

  9. Rules for system outputs • System output must go to a right address and be secure (encryption) • Single and double-key encryption and decryption can be used 3510 Systems Analysis & Design * Bob Travica

  10. Single-key encryption/decryption Double-key encryption/decryption Encryption and decryption Receiver (Server) can send Digital Certification issued by Certifying Authority and encrypted by CA’s private key, to get authenticated by Client. Client's browser usually has CA’s public key built in and thus decrypts the certificate. Sender (Client) can generate a private shared key for the session, encrypt it by Server’s public key, and send it to Server. 3510 Systems Analysis & Design * Bob Travica

  11. Double-key encryption/decryption Encryption and decryption Possible secure communication process: 1. Sender (Client) requests Receiver’s (Server) authentication and secure connection. 2. Receiver (Server) sends Digital Certification issued by Certifying Authority (CA) and encrypted by CA’s private key, to get authenticated by Client. 3. Client's browser decrypts message using CA’s public key built into Client's browser. 4. Client sends its public key to the Server, and Server sends its public key to the Client. Connection is secured from that point on as both will encrypt messages with public keys. Or: Either side generates a private key for the session, encrypts it by the other side’s public key, & sends it over. Connection is secured as in single private key encryption model. 3510 Systems Analysis & Design * Bob Travica

More Related