1. The use case diagram

Use case diagrams describe the relationships and dependencies between groups of use cases and actors involved in the process. Use Case describes a point of view of the person in the group of actions that lead to a specific result. Use cases are descriptions of typical interactions between users of the system and the system itself. They represent the external interface of the system and indicate the form of what the system should do (that is, not how). When you work with use cases it is important to remember a few simple rules: each use refers to at least one character of the person, each use case is the initiator, each use case leads to the corresponding result. Use cases can also interact with other use cases. The three most common types of interactions between use cases are listed below. Turning indicates that embodiment use is embedded in another embodiment use. Actor is an external source (not part of the system) that interacts with the system through the use case. Characters can be as real people (for example, users of the system) and other computer systems or external events. Due to their simplistic nature, use case diagrams can be a good communication tool for stakeholders. The drawings attempt to mimic the real world and provide a view for the stakeholder to understand how the system is going to be designed.  The purpose of the use case diagrams is simply to provide the high level view of the system and convey the requirements in layman's terms for the stakeholders. Additional diagrams and documentation can be used to provide a complete functional and technical view of the system. In Figure 4, drawn an example of a chart.

 

Figure 4 - Example of a use case diagram

2.5.2 The sequence diagram

In UML, each interaction is described by a set of messages that are involved in it the objects communicate with each other. Message is a complete piece of information that is sent by one entity to another. Receiving a message triggers a specific action to address a specific task by the object to which the message was sent. Thus, the message is not only convey some information, but also require or intend to perform the expected action from the receiving entity. Messages can initiate execution of transactions subject to the class, and the parameters of these transactions are transmitted with the message. On a sequence diagram, all messages in order of the time of its inception in the modeled system. In this context, each message has a direction from the object, which initiates and sends a message to the object that it receives. Sometimes the sender of a message is called the client, and the recipient's server. Then a message from a client is in the form of a service request, and the server response to the request after receiving a message can be linked to the performance of certain acts or transfer the necessary information to the client in the form of a message, too. Messages are represented by horizontal arrows connecting the line of life or focus on the management of the two objects sequence diagram. The UML distinguishes several types of messages, each of which has a graphic. On the sequence diagram depicted only those objects that are directly involved in the interaction. The key point for sequence diagrams is the dynamics of the interaction of objects over time. In the UML sequence diagram has two dimensions, as it were. The first left as vertical lines, each line shows the lifetime of an individual object involved in the interaction. The extreme left of the diagram depicted object that initiated the interaction. Depicted to the right of the other, which communicates directly with the first. Thus, all of the objects in the sequence diagram form a certain order determined by the order or the level of activity of objects in interaction with each other. Graphically, each object is represented by a rectangle and is located in the upper part of his life line. Inside the rectangle is written the name of the object and the class name separated by a colon. The entire record is emphasized as a sign of the object. The second dimension is a sequence diagram of the vertical time axis is directed from the top down. Initial time corresponds to the uppermost part of the diagram. Interaction of objects implemented via messages that are sent among other objects. Messages are shown as horizontal arrows with the message name, and their order is determined by the time of occurrence. That is, the messages are located in the sequence diagram above, initiated before those that are below. The scale on the time axis is not specified as a sequence diagram models the interactions of the temporal ordering of the "before-after". In Figure 5, drawn an example of a sequence diagram

Figure 5 - Sequence Diagram

3. Implementation of the project

This section is the most important part of the graduation project. This section will describe all of the classes, methods, variables, application, php scripts and database. UML diagrams are drawn[12]. This part also includes instructions about how to use the program.

3.1 Architecture of application

Figure 6 - The use case diagram

Figure 6, shows the use case diagram. Where USER is shown, the user can interact with the application. It can send contacts in the application, request contacts and update your contacts. SERVER - plays a role as a store of contacts, and gives an account name in the application, if required. The Application - acts as a buffer between the user and the server. The interaction with the user is prompted to store and edit contacts. [13]

Figure 7 - The sequence diagram.

Figure 7 shows the sequence diagram. Here you can see the sequence of actions as the action happens.

1: User presses the registration button

2: Application asks for login and password

3: User gives that information

4: Application approves user information

5: If the USER identification is valid then the application displays a welcome message to user

6: User presses the send contacts button

7: Application gets contacts and sends to server

Figure 8 - Diagram Databases

Figure 8 shows the database[16]. The database contains two tables: Users and Contact. Table Users is designed to store information about the user. Table Users contains columns id, login and password. Column id’s type is “int (255) serial” Primary key. When you add a user to the database the id is automatically increased by one unit. Column login’s type is “varchar (50).” The longest password can be 50 characters. Column password’s type is «varchar (50)."The longest login can have 50 characters.

Table Contacts is designed to store telephone contact person. Table Contacts contains columns id, name, surname, userId, number. Column id’s type is “int (255) serial” Primary key. When you add one contact id is automatically increased by one unit. Type of name column is «varchar (50)." The longest name of a contact can have 50 characters. Type of column surname is «varchar (50)." The longest name can have 50 characters. Type of column userId is «int (255) serial» Foreign key. Used to know who owns this contact. Type of column number is «varchar (50)." This column is used to store phone numbers.

3.2 Description of the classes

The following are descriptions of the main classes in the development of applications for the Android OS with a centralized repository for contact information in address book.

3.2.1 MainActivity.java[11]

This class is main class of application. It opens main page of application from MainActivity.xml file.

Description of the functions and variables of the class MainActivity.java

protected void onCreate (Bundle savedInstanceState) - it is a function of the main interface for querying

public void onClick (View v) - this function starts when you press the button, and it sends to login page or register page.

Table 2 – variables of class MainActivity.java

Name	Type	Description
Reg	Button	This variable of type button, if pressed sends to registration page
Login	Button	This variable of type button, if pressed sends to login page
Intent	Intent	To create a new intend