Software Interface Description
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
Imported Object (RFC, IDoc)
Message Type (Fault)
Data Type (Enhancement)
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)
And the following is a diagram showing how a relevant asynchronous communication takes place
Service Interface (Inbound)
Service Interface (Outbound)
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
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:
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.