Understanding Online Appointment System – Data Flow Diagram – Tutorials

Description of Online Appointment System

What is an Online Appointment system?

An Online Appointment System is an information system generally based on web from where a client can make an appointment with the person of his interest. In a simple sense it is the information system you use to make an appointment to any organization or institute or personnel like Hospital, Doctors, Attorney, Consultant, Teachers, Schools and Universities. It can be done by making a phone call to the reception or customer care or even via Internet.

How does an Online Appointment System Works?

A very simple tutorial model of how an online appointment system function is shown by the figure below.

Figure: Description of Online Appointment System

Description of Online Appointment System

Description of Online Appointment System, How it works?

Description of Online Appointment System

In above figure, it describes clients can make an appointment by calling to the customer care of the organization or by calling to the reception on office or even by visiting the official website of particular institution. In this system a client is given to fill a form or order a ticket or s/he can also select the parties for the appointment. Agents like customer care, reception and web forms helps clients to communicate easy with the online appointment system.

See more: Issuing out book from Library; Library Management System

Data Flow Diagrams: Online Appointment System

Using the general symbols of DFD I have prepare a context diagram and Level-1 DFD so that you can understand the system in broad.

Context Diagram of Online Appointment System

Context Diagram of Online Appointment System

Figure 1: Context Diagram of Online Appointment System

In this context diagram, you can see only one process named ‘Online appointment System’, with two external interactions or entities namely Clients and Reception/Web Forms.

Level-1 DFD of Online Appointment System

Level-1 DFD of Online Appointment System

Figure 2: Level-1 DFD of Online Appointment System

In above Data Flow Diagram, there are three different process one which ‘Interact with Clients’, next that ‘Generate Clients Ids’ and another that ‘Fetch Appropriate Date/Time’. External Entities in this Level-1 DFD are Clients, Reception/ Web Forms and Organization/ Personnel.

I hope this DFD will become advantage to explore your knowledge about how online appointment system works. But, remember this system is just an example and it only describes a simple model so, there can be many other models for online appointment system.

Tutorial on How to draw Data Flow Diagram – Train and Air Ticket Reservation System – Example

Train Ticket Reservation System; Context Diagram

Train and Air Ticket Reservation System – Data Flow Diagram – Example

Train Ticket reservation system is a very complicated system. It is complicated because it consists of more number of entities and processes. Data in this system should be collected from more number of entities and need to be processed within more number of processes. Example of this type of system is explained below:

Explanation:

This Train Ticket Reservation System consists of four external entities; namely Customer, Vendor, Schedule manager and Train representative. Customer are the one who issue for the tickets, Vendor are the counterman who receives payment to handover tickets to the customer, Schedule manager manages the time schedules of train with accordance to the route and Train Representative monitors the overall activities on the system like the seats capability and passenger facility. These four entities are governed by the single or multiple processes through the flow of data.

This Data Flow Diagram was taken directly from my notes so if you have any problems in understanding it, you are kindly requested to leave comment below.

The standard of naming process-name is; process name should be action verb that specifies the operation(see on: How do we begin to construct Data Flow Diagrams? ). Advantage of preparing this DFD can be; proper knowledge of Data flow, effects of external entities in the system, determination of process in the overall system.

The table below shows the data attributes by the corresponding entity:

Entity Outgoing Data Attributes Incoming Data Attributes
Customer C_name, Route, Prefered_date, payment, seat_prefered Tickets, Time_of_departure
Vendor Tickets C_name, Route, Prefered_date, Payment
Schedule Manager Departure_time, Routes Routes, Prefered_date
Train Representative Seat_no Seat_prefered

In the context diagram of DFD; general symbols of DFD are used to prepare a simple model. Four different entities are bounded by the dataflow with the process Ticket Reservation. Whenever a customer needs tickets then he gives his information and pays for the ticket, vendor with the information from schedule manager and train representative provides customer with tickets if available.

Train Ticket Reservation System; Context Diagram

Train Ticket Reservation System; Context Diagram

Figure: Train Ticket Reservation System; Context Diagram                   

Similarly, in Level 1 DFD entities are same but process is broken down into other sub processes which would help to clarify the system in better way. In this model, Ticket Reservation process is further divided into four respective processes; namely Reserve Ticket, Create Bills, Check Seats available and Check Schedule. Process name are given number as prefix. Besides processes there are three databases; namely tickets_db, bills_db and schedules_db for storage of tickets, bills and schedules respectively.

Train Ticket Reservation System; Level 1 DFD

Train Ticket Reservation System; Level 1 DFD

Figure: Train Ticket Reservation System; Level 1 DFD

All four processes do their different jobs and integrate to a system so as to reserve Train Tickets. From a successful run of the process finally a ticket can be reserved.

We hope by this DFD you are clear the method of reserving a ticket for train, now you can implement this idea onto your projects. This type of model will be very helpful for the projects like Train Ticket Reservation System, Air Ticket Reservation System and any other ticket reservation system.

Although this example was taken from one of my daily assessment, I hope this example will definitely help you in modeling your projects and assessments. You can also add other processes, entities, data attributes and data objects to make the system clearer and board. Find more of Examples of DFD here: Data Flow Diagram

Tutorial on How to draw Data Flow Diagrams – Withdraw Mark-sheet from University – Example

Mark-sheet Withdrawing System; Context Diagram

Withdraw mark-sheet from University – Data Flow Diagram – Example

System for withdrawing mark-sheet from the University is a very simple system. When it comes to design model of this system by using Symbols of DFD then we might have to work with our mind. Here, I have posted an example of withdrawing mark-sheet from university.

Explanation:

This mark-sheet withdrawing system consist of three entities; namely Student, Administrator and Accountant. Student are the one to withdraw mark-sheet from the system, Administrator plays role in providing mark-sheet to the student after the confirmation of the data and Accountant confirms the account clearance of the student. These three entities are bounded by one or multiple process in the system with flow of data.

This Data Flow Diagram was taken directly from my notes so if you have any problems in understanding it, you are kindly requested to leave comment below.

The standard of naming process-name is; process name should be action verb that specifies the operation(see on: How do we begin to construct Data Flow Diagrams? ). Advantage of preparing this DFD can be; proper knowledge of Data flow, effects of external entities in the system, determination of process in the overall system.

In the context diagram of DFD; general symbols of DFD are used to prepare a simple model. Three different entities are bounded by the data flow within the process Withdraw Mark-sheet. Whenever a student desire to withdraw mark-sheet then he gives his information and at the same time pays the bills if any of it is due, accountant checks for account clearance of the system and confirms no due remains and with this confirmation administrator processes for mark-sheet to be given for student.

Mark-sheet Withdrawing System; Context Diagram

Mark-sheet Withdrawing System; Context Diagram

Figure: Mark-sheet withdrawing system; Context Diagram

Similarly, in Level 1 DFD entities are same but process is broken down into other sub processes which would help to clarify the system in better way. In this model, Withdraw Marksheet process is further divided into three respective processes; namely Student Records, Check Account Clearance and Get Marksheet. Besides processes there are three databases; namely student_db, account_db and marks_db for storage of student details, account information and marks in different subjects respectively.

Mark-sheet Withdrawing System; Level 1 DFD

Mark-sheet Withdrawing System; Level 1 DFD

Figure: Mark-sheet withdrawing System; Level 1 DFD

All three processes do their different jobs and integrate to a system so as to withdraw mark-sheet. From a successful run of the process finally a student can withdraw his/her marksheet.

We hope by this DFD you are clear the method of withdrawing mark-sheet from the university, now you can implement this idea onto your projects. This type of model will be very helpful for the projects like University Management System, Result Publication System and any other mark-sheet withdrawing system.

Although this example was taken from one of my daily assessment, I hope this example will definitely help you in modeling your projects and assessments. You can also add other processes, entities, data attributes and data objects to make the system clearer and board. Find more examples of DFD.

Returning a book to library – Data Flow Diagram – Example

Returning a book to library; Context Diagram

Returning a book to library – Data Flow Diagram – Example

After issuing a book from library, it is arbitrary to return the book in time. In this example we will discuss about the model of returning a book to library.

Explanation:

This system need to accept student information as input. Student information may contain student name, student id, and registration number and so on. The best can be student ID number that is usually not repeated (although registration number is not repeated, for now I choose student Id number). Yes, not only student information is sufficient input for this system, system should also accept the name to the book to be submitted/ returned. Advantage of preparing this DFD can be; proper knowledge of Data flow, effects of external entities in the system, determination of process in the overall system.

This Data Flow Diagram was taken directly from my notes so if you have any problems in understanding it, you are kindly requested to leave comment below.

In this context diagram of DFD; general symbols of DFD are used to prepare a simple model. Students, Librarian and Head of Library are the external entities. Process name is Returning Books to Library.

Returning a book to library; Context Diagram

Returning a book to library; Context Diagram

Figure: Returning a book to Library; Context Diagram

The standard of naming process-name is; process name should be action verb that specifies the operation(see on: How do we begin to construct Data Flow Diagrams? ). Data Flow contains the data to be exchanged throughout the system from external entities to data stores through process. And obviously, entities are real objects that take part in the system.

Similarly, in Level 1 DFD external entities are same but processes are break down into two or more process; so as to clarify each of the operation separately. The process is broken into two processes; Check Book on Library and Generate Report.

Returning a book to library; Level 1 DFD

Returning a book to library; Level 1 DFD

 

Figure: Returning a Book to Library; Level 1 DFD

In Level 1 DFD we show the database objects used. Here we use two database; book_db and issue_db. Book_db stores the data of book_name, book_to_return and books_on_rack. Similarly, issue_db stores data like books_left_to_return, book_submitted and submission_date. Both the process uses data form data base for records and data manipulation.

We hope by this DFD you are clear the method of returning a book to the library, now you can implement this idea onto your projects. This type of model will be very helpful for the projects like Library Management System.

Issuing Item from Department Store – Data Flow Diagram – Example

Issuing items form Departmental Store DFD

Issuing Item from Departmental Store

Explanation:

This system is a sub system of Departmental Store Management System. It can work as a single function. This function/system takes inputs form customers. A customer gives item_name and item_quantity as inputs. At the same time the system check the availability of the item and ask for payment from customers. Customer pays and receives bills. Bills are generated by the system. Vendor in this system acts as secondary users they also give item_name and item_quantity as inputs to the process, confirms the payment made and process for bills to be generated.

This Data Flow Diagram was taken directly from my notes so if you have any problems in understanding it, you are kindly requested to leave comment below.

A simple context diagram of this system can be drawn as below with the general symbols used in DFD. This context diagram describes the flow of inputs to the system. A process is named as Issuing Items. External entities such as customer and vendor take part in this system.

Issuing items form Departmental Store DFD

Issuing items form Departmental Store Context Diagram DFD

Figure 1 Context diagram of DFD Issuing Item from a departmental store

Similarly, Level 1 DFD is drawn to explain the system in detail. Above context diagram is broken into small functions to give a prefect vision how the system works. For this system, we broke the process into four different functions. For the storage of data we have used three different data stores, now external entities are customer, vendor/cashier and manager.

Issuing Items from Departmental Store Level - 1 DFD

Issuing Items from Departmental Store Level – 1 DFD

Figure 2 Level-1 DFD for Issuing Item from a departmental store

Description of Level – 1 DFD

The whole system is initialized by the action of Customer (external entity). In Level – 1 DFD there are four processes, namely Check Item Rates, Create Bills, Update Sales and Generate Report. Data are stored in Data Stores namely, Items_db, Sales_db, and Bills_db. As in a departmental store when a customer wants to buy something s/he first looks at the item rate and then decides whether or not to buy that good. In same way, our system also takes the item_name and item_quantity as inputs form customers and checks for the item rate and calculate the sum, to check item rate system fetches data form Items_db data-store. This is done by Check Item Rate process. When an item is to be issued, the system checks on the data store for the availability of items. Customer pays for item issued, when payment is confirmed by cashier then bills are created by Create Bills process. Sales are updated by Update Sales process. Lastly, reports are generated by Generate Reports Process. Reports are to be checked by head of store/ or manager.

Different from Issuing books from Library, this data flow diagram will surely help you when developing Departmental Store Management System and it’s idea will definitely help in designing similar other DFDs. In you have any problem understanding this DFD you can leave it in comments below.

 

Issuing out a book from a library – Data Flow Diagram – Example

Issuing out a book from a library-Context Diagram DFD

 Issuing out a book from a library

Explanation:

This system need to accept student information as input. Student information may contain student name, roll number, registration number and so on. The best can be roll number that is usually not repeated (although registration number is not repeated, for now I choose roll no). Advantage of preparing this DFD can be; proper knowledge of Data flow, effects of external entities in the system, determination of process in the overall system.(see also Symbols Used in DFD)

This Data Flow Diagram was taken directly from my notes so if you have any problems in understanding it, you are kindly requested to leave comment below.

In this context diagram of DFD; general symbols of DFD are used to prepare a simple model. Students, Librarian and Head of Library are the external entities. Process name is Issuing Books. The thing is, process name should be action verb that specifies the operation. Data Flow contains the data to be exchanged throughout the system from external entities to data stores through process.

Issuing out a book from a library-Context Diagram DFD

Issuing out a book from a library-Context Diagram DFD

Figure: Context Diagram- Issuing Books from library

Similarly, in Level 1 DFD external entities are same but processes are break down so as to clarify the operation separately.

Issuing out a book from a library- Level 1 DFD

Issuing out a book from a library- Level 1 DFD

Figure: Level 1 DFD- Issuing Books from library

We hope by this DFD you are clear the method of issuing out a book from a library, now you can implement this idea onto your projects proposals and case study.

 

Advantages and Disadvantages of the DFD Data Flow Diagrams

Leveled DFD for Record and Pay Invoices process

Advantages of the Data Flow Diagram

System analyst in some extent, argue Data Flow Diagrams as this procedure takes long time of modeling. But what’s the alternative? The DFD offers the analyst with several distinct advantages. Some of them are shown there in list:

  1. Most fundamentally, it depicts flow and boundary. The essence of knowing boundary is first to understand the extent of the process prior to beginning to define something that may not be complete or accurate.
  2. The concept is typically known as top-down, but the effort can also be conceived as step-by-step. The analyst must first understand the boundary and flows prior to doing anything else. The steps following this will procedurally gather more detailed information until the specification is complete.
  3. Another important aspect of the DFD is that it represents a graphical display of the process and is therefore a usable document that can be shown to both users and programmers, serving the former as process verification and the latter as the schematic (blueprint) of the system from a technical perspective.
  4. It can be used in JAD(Joint Application Design) sessions and as part of the business specification documentation. Most important, it can be used for maintaining and enhancing a process.
  5. Using least numbers of Symbols make design of DFD a easy task.

Disadvantages of the DFD

Besides of those distinct advantages; there are some disadvantages as well. Some of them are listed below:

  1. The biggest drawback of the DFD is that it simply takes a long time to create: so long that the analyst may not receive support from management to complete it. This can be especially true when there is a lot of leveling to be performed. Therefore, many firms shy away from the DFD on the basis that it is not practical.
  2. The other disadvantage of the DFD is that it does not model time-dependent behavior well, that is, the DFD is based on very finite processes that typically have a very definable start and finish. This, of course, is not true of all processes, especially those that are event driven.
  3. The best solution to the time-consuming leveling dilemma is to avoid it as much as possible. That is, you should avoid starting at too high a summary level and try to get to the functional primitive as soon as you can. If in our example, for instance, the analyst had initially seen that the DFD had two processes instead of one, then the parent process could have been eliminated altogether.

This would have resulted in an initial functional primitive DFD at Level 1. The only way to achieve this efficiency on a consistent basis is through practice. Practice will eventually result in the development of your own analysis style or approach. The one-in, one-out principle of the logical equivalent is an excellent way of setting up each process. Using this method, every event description that satisfies one-in, one-out will become a separate functional primitive process. Using this procedure virtually eliminates leveling. Sometimes users will request to see a summary-level DFD. In these cases the functional primitives can be easily combined or “leveled-up.”

Moreover, you can see our article on ” How do we begin to construct Data Flow Diagrams (DFDs)?” for exploring your ideas of designing DFDs.

Difference between Physical and Logical Data Flow Diagrams

Physical Data Flow Diagram for cashing cheque

Difference between Logical DFD and Physical DFD

So far we considered data flow diagrams as logical models. They specify the logical process preformed on the data, i.e. the type of operations performed. Beside that logical DFDs doesn’t specify who does the operation, whether it is done manually or by computer and also where it is done. But physical DFD specifies these.  For example, in figure 1(a), a physical DFD specifies that a checking clerk receives the items from vendors, checks them and rejects an item if it is not as per order. Accepted items are sent to a stores clerk who updates the inventory file. Figure 1(b), a logical DFD shows the type of operation preformed. Although the DFD is Physical or Logical but symbols used in the DFD are same.

 

Physical Data Flow Diagram - Example

Physical Data Flow Diagram – Example

A physical DFD can be taken as the first stage for the development of logical DFD; it can be easily drawn while gathering the facts at the first step of SDLC. It can be verified by the user.

Logical Data Flow Diagram - Example

Logical Data Flow Diagram – Example

Example:

As an example, we can consider the development of a physical and logical DFD for the process of getting a cheque cashed in a bank.

Starting to build DFD is very simple if you start from Physical DFD and reach to Logical DFD.

Operation:

A customer presents a cheque to a clerk. The clerk checks a ledger containing all account numbers and makes sure whether the account number in the cheque is valid, whether adequate balance is there in the account to pay the cheque, and whether the signature is authentic. After the positive report of the above operation, clerk gives the token to the customer. The clerk also debits customer’s account by the amount specified in the cheque.  If the cash cannot be paid due to an error in the cheque, the cheque is returned. The token number is written on the top of the cheque, customer gives the cheque to the cashier, when the token number is called out by the cashier the customer goes to cashier with the token. The cashier checks token number, takes customer’s signature, pays cash, enters cash paid in a ledger called day book, and files the cheque.

To explain this operation, I have modeled two different DFDs, a physical and logical. The physical DFD for this operation is given in Figure in 2(a).

 

Physical Data Flow Diagram for cashing cheque

Physical Data Flow Diagram for cashing cheque

Same physical DFD is converted into logical DFD, by taking the functions performed at each step as same. In logical DFD each process has a well defined operation. Further, in this diagram we do not include details such as clerks/cashiers performing operations. Logical DFD for this operation is shown in Figure 2(b).

 

Logical Data Flow Diagram for cashing Cheque

Logical Data Flow Diagram for cashing Cheque

So, concept physical and logical DFD will definitely help you in completing your project, preparing proposals and submitting Case study on your project

How do we begin to construct Data Flow Diagrams (DFDs)?

Leveled DFD for Record and Pay Invoices process

How do we begin to construct Data Flow Diagrams (DFDs)?

Hope you have read our previous articles on Concept of Data Flow Diagrams and Symbols used in Data Flow Diagrams before starting to construct Data Flow Diagrams.

So here is a top-down process you need to follow to draw DFD in a easy way:

  1. Draw a bubble/circle to represent the process you are about to define.
  2.  Ask yourself what thing(s) initiate the process: what is coming in? You will find it advantageous to be consistent in where you show process inputs. Try to model them to the left of the process. You will later be able to immediately define your process inputs when looking back at your DFD, especially when using them for system enhancements.
  3.  Determine the process outputs, or what things are coming out, and model them to the right of the process as best you can.
  4. Establish all files, forms or other components that the process needs to complete its transformation. These are usually data stores that are utilized during processing. Model these items either above or below the process.
  5.  Name and number the process by its result. For example, if a process produces invoices, label it “Create Invoices.” If the process accomplishes more than one event, label it by using the “and” conjunction. This method will allow you to determine whether the process is a functional primitive. Ultimately, the name of the process should be one that most closely associates the DFD with what the user does. Therefore, name it what the user calls it! The number of the process simply allows the analyst to identify it to the system and most important to establish the link to its children levels during functional decomposition.

Let us now apply this procedure to the example below:

Vendors send Mary invoices for payment. Mary stamps on the invoice the date received and matches the invoice with the original purchase order request. Invoices are placed in the Accounts Payable folder. Invoices that exceed thirty days are paid by check in two-week intervals

.

Step 1: Draw the bubble

A process bubble used in Data Flow Diagram

A process bubble used in Data Flow Diagram

 

Figure 1: A process bubble.

Step 2: Determine the inputs

In this example we are receiving an invoice from a Vendor. The Vendor is considered a Terminator since it is a boundary of the input and the user cannot control when and how the invoice will arrive. The invoice itself is represented as a data flow coming from the Vendor terminator into the process as shown in Figure 2:

 

Vendor invoice (as entity) to process to DFD

Vendor invoice (as entity) to process to DFD

Figure 2: Terminator sending invoice to the process.

Step 3: Determine the outputs of the process

In this case the output of the process is that the Vendor receives a check for payment as shown in Figure 3:

 

DFD with output to the Vendor through Process

DFD with output to the Vendor through Process

Figure 3: DFD with output of check sent to vendor

 

Step 4: Determine the “processing” items required to complete the process

In this example, the user needs to:

  • match the invoice to the original purchase order;
  •  create a new account payable for the invoice in a file; and
  •  Eventually retrieve the invoice from the Accounts Payable file for payment.

Note that in Figure 4 the Purchase Order file is accessed for input (or retrieval) and therefore is modeled with the arrow coming into the process.

The Accounts Payable file, on the other hand, shows a two-sided arrow because entries are created (inserted) and retrieved (read). In addition, arrows to and from data stores may or may not contain data flow names. For reasons that will be explained later in the chapter, the inclusion of such names is not recommended.

 

DFD with interfaceing data store

DFD with interfaceing data store

Figure 4: DFD with interfacing data stores.

Step 5: Name and number the process based on its output or its user definition.

 

Final named DFD

Final named DFD

Figure 5: Final named DFD.

The process in Figure 5 is now a complete DFD that describes the event of the user. You may notice that the procedures for stamping the invoice with the receipt date and the specifics of retrieving purchase orders and accounts payable information are not explained. These other components will be defined using other modeling tools. Once again, the DFD reflects only data flow and boundary information of a process.

The DFD in Figure 5 can be leveled further to its functional primitive. The conjunction in the name of the process can sometimes help analysts to discover that there is actually more than one process within the event they are modeling.

Based on the procedure, the event really consists of two processes: Recording Vendor Invoices and Paying Vendor Invoices. Therefore, P1 can be leveled as shown in Figure 6.

Leveled DFD for Record and Pay Invoices process

Leveled DFD for Record and Pay Invoices process

Figure 6: Leveled DFD for Record and Pay Invoices process.

So, by this time I hope you are able to design DFD by using symbols used in DFD

Symbols used in Data Flow Diagrams (DFDs)

Process are denoted by circles in DFDs

Symbols used in Data Flow Diagrams (DFDs)

In previous article, we discussed about the concept of Data Flow Diagrams, now it’s time to learn some symbols used in it. Designing of model using concept of DFDs is an easy way because it uses not more than 4 simple notations. Using less number of notations makes it look simple and easily understandable. DFD consists of four notations for four different functions. Functions are processes, data flows (inputs or outputs), external entities and definitely data store. So, let’s explore the symbols used in Data Flow Diagrams. Continue Reading…

Concept of Data Flow Diagrams (DFD)

DFD - The interfaces required to design and build a system

Data Flow Diagrams

Concept of Data Flow Diagrams (abbreviated as DFDs) was introduced by De-Marco in 1978 and also by Gane and Sarnon in 1979. DFD is an important tool used by system analyst. In simple, DFD gives an outline modeling of the system to be built and also can be designed to study the data flow of already existing system in a graphical interface.

As an Architect who draws sketches of the house that is to be built, he does it after gathering the requirements of house buyer and then translates it into a blueprint that gathers all engineering requirement for the house. Misinterpretation may take place when an architect talks to the house buyer about the model of house with his words, surely house buyer won’t understand all his ideas. Once a wise man said that people understand 100% of what they see but only 50% of what they listen. So, to describe his model to house buyer architect can use drawings and models.

In a similar way, a system analyst compared to an architect and user to house buyer. A meeting between these two parties to get an output of usually two types; a business requirement outline and prototype of the way the system will function, and a schematic represented by modeling tools for programmers. This meeting can be taken as the requirement gathering session of System Development Life Cycle (SDLC).

The interfaces required to design and build a house - a concept of Data Flow Diagram in Visio

The interfaces required to design and build a house – a concept of Data Flow Diagram in Visio

Figure 1 – The interfaces required to design and build a house

The interfaces required to design and build a system

The interfaces required to design and build a system

 

Figure 2 – The interfaces required to design and build a system

So, a DFD models a system by using external entities from which data flows to a process which transforms the data and creates output data flows which go to other processes or external entities or data stored. Similarly, stored data may also flow to processes as inputs. DFD is perfect and simple way of modeling a system for ease of understanding and at the same time is very flexible too. Designing of DFD is easy and simple because it uses only four symbols. Least number of symbols used in DFD makes it look neat and is easy to understand.