iMessageSimulator

A simulation of a message aplication focused on the implementation of the queues data structure

It is an academic exercise that it must meet the following requirements:

A queue is an Abstract Data Type (TDA) that allows the storage of a collection of values of a certain type and is characterized by the property that the first value added to the collection is the first that can be extracted from it. There are many applications of queues in troubleshooting problems with computers: the operating system print queue and the e-mail message output queue are two examples of everyday use. Queue operations, such as TDA, will be: Enqueue(...), Extract(...) and IsEmpty(...). Implement a sequential variant of the TDA queue that satisfies the following requirements:

• Any type of information may be collected.
• When the array is filled, the queue should increase the size of the array so that five more values can be stored.
• The arrangement must be used in a "circular" way and without a "head node", to make a rational use of the space. To illustrate how the queue works, an application that simulates an email system will be implemented. The main form of the application will simulate the mail client, through which the (unique) user will be able to review his messages and send messages to other users with clients on his mail server or on others (assume that the user's server processes messages addressed only to the user, coming from other servers). This form will have the "Connect..." button, which simulates the connection to the server. When you press it, a second form will be displayed, corresponding to the mail server. At that point, the client sends all messages from the user's outbox (in the same order in which the user sent them), and then receives all messages from the server intended for the user (in the same order they were placed on that server), either from other clients on the server or from other servers. In the form of the The list of recipients of the messages sent by the user (after each connection) will be displayed, as well as the list of senders of the messages intended for the user (before each connection). Additionally, the main form menu will have, among others, the options "Sent..." and "Server...". The first one will show the list of recipients to whom the user has sent messages (before making the connection to the server). The second also shows the server form and offers the possibility of simulating the receipt, by the server, of the messages intended for the user. To do this, messages addressed to the user can be generated, with their respective texts, but only the list of senders of these messages will be displayed. The order in which these were generated will be maintained. When the client "connects" to the server, the latter's form updates the list of recipients of the user's messages (simulating that the server is waiting for other users to download their messages or for the connection to other servers to take place for the processing of outgoing messaging) and, When you deliver messages to the client, the sender list on the server is "cleaned up" and the sender list on the main form is updated. At any time, the user will be able to see the text of a message, selecting its sender in that relationship (inbox). The user will have the option of deleting one or more messages from their inboxes and outboxes, after selecting the sender(s) or recipient(s) of said message(s), respectively. To remove from the output tray, an auxiliary battery must be used. Similarly, the server may delete the list of recipients or messages intended for the user, after selecting said recipients or senders, respectively. Similarly, an auxiliary stack will be required to delete messages intended for the user. The server and user IDs are known, and recipients are formed from those of the corresponding servers (idusuario@idservidor). For each message, the sender, the recipient and its text are known. When closed, the application must allow the persistence of all messages (received and outgoing) from the client and those from the server (received from the client and destined for the user).