Message Oriented Application - Banking - Lecture Slides, Slides of Banking and Finance

Download Message Oriented Application - Banking - Lecture Slides and more Slides Banking and Finance in PDF only on Docsity!

Example of a Message-oriented application

The Message-oriented architecture and

design principles

1. Divide and conquer : The application is made of isolated software components.
2. Reduce coupling : The components are loosely coupled since they share only data format.
3. Increase abstraction : The prescribed format of the messages are generally simple to manipulate, all the application details being hidden behind the messaging system.
4. Increase reusability : A component will be resusable is the message formats are flexible enough.
5. Increase reuse : The components can be reused as long as the new system adhere to the proposed message formats.

Summary of architecture versus design

principles

Multi-layers

Client-server

Broker

Transaction processing

Pipe-and-filter

MVC

Service-oriented

Message-oriented

9.7 Writing a Good Design Document

Design documents as an aid to making better designs

• They force you to be explicit and consider the important

issues before starting implementation.

• They allow a group of people to review the design and

therefore to improve it.

• Design documents as a means of communication.

—To those who will be implementing the design.

—To those who will need, in the future, to modify the

design.

—To those who need to create systems or subsystems

that interface with the system being designed.

When writing the document

• Avoid documenting information that would be readily

obvious to a skilled programmer or designer.

• Avoid writing details in a design document that would

be better placed as comments in the code.

• Avoid writing details that can be extracted automatically

from the code, such as the list of public methods.

9.8 Design of a Feature of the SimpleChat

System

A. Purpose This document describes important aspects of the implementation of the #block, #unblock, #whoiblock and #whoblocksme commands of the SimpleChat system.

B. General Priorities Decisions in this document are made based on the following priorities (most important first): Maintainability, Usability, Portability, Efficiency

C. Outline of the design Blocking information will be maintained in the ConnectionToClient objects. The various commands will update and query the data using setValue and getValue.

Design Example

E. Details of the design:

Client side:

• The four new commands will be accepted by handleMessageFromClientUI and passed unchanged to the server.
• Responses from the server will be displayed on the UI. There will be no need for handleMessageFromServer to understand that the responses are replies to the commands.

Design Example

Server side:

• Method handleMessageFromClient will interpret #block commands by adding a record of the block in the data associated with the originating client. This method will modify the data in response to #unblock.
• The information will be stored by calling setValue("blockedUsers", arg) where arg is a Vector containing the names of the blocked users.
• Method handleMessageFromServerUI will also have to have an implementation of #block and #unblock. These will have to save the blocked users as elements of a new instance variable declared thus: Vector blockedUsers;

Design example

• The #forward, #msg and #private commands will be

modified as needed to reflect the specifications.

Each of these will each examine the relevant blockedUsers vectors and take appropriate action.

9.9 Difficulties and Risks in Design

Like modelling, design is a skill that requires considerable

experience

— Individual software engineers should not attempt the

design of large systems

— Aspiring software architects should actively study

designs of other systems

Poor designs can lead to expensive maintenance

— Ensure you follow the principles discussed in this

chapter