Software Interface Description

Software Interface Description

Student’s Name

Name of Institution

 

 

Date of submission

System’s Attribute and their Definitions

Quality Attribute Definition

Performance A system’s ability to respond to functions

Usability A system’s ability to be utilized effectively

Reusability A system’s ability to be used more than once and maintain functionality

Reliability A system’s ability to be used over a long time to come

Testability A system’s ability to be facilitate its performance

Supportability A system’s ability to be maintained in an operational manner

Flexibility A system’s ability to be modified to specific designs

Security A system’s ability to deny service to unauthorized users

Maintainability A system’s ability to undergo changes and maintain it’s performance

Agility A system’s ability to rapidly undergo change

Scalability A system’s ability to support, maintain, and increase system demand

Interoperability A system’s ability to exchange data with other systems

Software interface description:

The objects that are in use in a software interface are;

Service Interface – the function of this object is to make definitions on the set of functions that are provided. These functions can be the ones used by an application or the ones provided for by the application and can have either one or more operations.

Message Type – this object is meant to define a message’s root element and then refer to the type of data.

Data Type – this object is meant to define the structure of the data.

External Definition – this object is meant to define the structure of data that the ES Repository imports.

Imported Object – this object is the IDoc or the RFC that is imported into the ES Repository.

Context Object – this object is meant to abbreviate XPath expressions and address the specificity of payload element.

The graphical representation of software interface objects is as shown below

Service Interface

Operation

Context Object

Imported Object (RFC, IDoc)

Message Type (Fault)

Data Type (Enhancement)

External Definition

The two types of communication operations that can take place effectively in a function depend on the attributes specified on it. These attributes can result into an asynchronous communication, where a message is requested without the expectation of a response. For this to happen, the programmer delegates a task to the message type that does not provide the response, the task delegated is the fault. The attributes can also result into a synchronous communication, where a message id requested with an expected response. For this to happen, the programmer can delegates three tasks to provide the response expected, these tasks are fault, response, and request.

The following diagram shows how a relevant synchronous communication takes place.

Service Interface (Outbound)

Service Interface (Inbound)

Message Requested

Server

Client

Operation

Message Response

Operation

And the following is a diagram showing how a relevant asynchronous communication takes place

Service Interface (Inbound)

Service Interface (Outbound)

Message Requested

Client

Server

Operation

Operation

DFD System for B&B

The following is a mail delivery system that B&B uses to deliver goods to its client. The system allows B&B clients to conduct shopping while in their homes where they place an order to the company via emails, telephone calls, or faxes. Upon receiving an order, the company delivers goods together with their invoice to the client. Once the client has received the goods and approves they are the right ones, s/he sends money for payment and receives the due receipt to complete the transaction.

The DFD below shows how information is exchanged between the client and the company

CataloguePayment

Receipt

Order

Goods

Invoice

Delivery Note

Client

Client

B&B’s Mail Order System

Note: Once the system receives an order, it sends out an invoice, a catalogue, and goods to the client. Upon receiving payment from the client, it sends out a receipt to complete the transaction.

B&B’s Level 1 DFD

In order to give more details of B&B’s system transactions, a level 1 DFD is implemented to give more illustrations on the company’s system’s function ability. B&B’s level 1 DFD is represented as shown below.

Note: data flows from Level 0 DFD are included to complete Level 1 functionality.

For this to be complete, there are three rules that must be applied to ensure that Level 1 DFD is valid. These rules are;

Rule 1 – Each function must have input and output?

Rule 2 – Each function must have all the right information to produce an output?

Rule 3 – If not, what other information is needed and from where?

When applying the ‘Rules’ the expected results are;

Rule 1: Answer YES.

Rule 2: Function 1: YES – it has all the information needed to produce an invoice.

Function 2: NO – it lacks all the information needed to produce a receipt. This calls for rule 3.

Rule 3: For function 2 to match order with payment, it relies on the order information given by the client in function 1. The system is expected to have stored this information for any further use. The DFD becomes;

Note: Function 1 generates and stores data and Function 2 reads data from the storage. For a complete diagram, all rules must be applied.

Level 2 DFD

In this case, the system is made to process two functions.

Process Order for Function 1, where there is the reception of order and issuance of invoice and goods.

Process Payment for Function 2, where there is reception of payments and issuance of catalogue and receipts.

Diagramatically, function boxes are expanded to contain every function. This displays the correctness of data flow from Level 1 to Level 2.

After applying the three rules, the updated diagram for function one and two becomes:

Updated Diagram

Function One:

Function Two:

When the three rules of DFD are applied to the system, the updated diagram becomes:

Note: the problem of no output has been solved and this situation common.