PHP Team Development — Save 50%
Easy and effective team work using MVC, agile development, source control, testing, bug tracking, and more
In this article by Samisa Abeysinghe, we will look into a process model that we can use as a starting point for the PHP projects that we are working on. The process is designed with the MVC framework based design model in mind. It is assumed that the workload is broken down based on the Model-View-Controller pattern, and team members are assigned to work on each layer based on that breakdown.
The process model clearly depicts how the separate concerns such as the data layer, the business layer, and the presentation layer can be worked on in parallel, and at the same time, how those separate concerns fit with each other to form the entire system. If you carefully evaluate this process model, there is no activity for system integration. So one might question how the separate layers would be integrated with each other. However, if you pay attention to the design and implementation details of each layer, you will notice the dependencies mentioned in each layer, which lead to the integration. For example, business logic implementation requires the concrete database design, as well as the data access layer. The final user interface implementation would be done on top of the business logic implementation. Therefore, the integration of these independent layers happens seamlessly, along the way, in the process. If the team follows the process as it is, the integration would result in naturally.
The initial activity of the process model is to analyze the user requirements. It is obvious that in any software project, the first and foremost activity is to have an understanding of what the users require.
There are various tools and techniques to analyze user requirements. However, it is important to note that, while it is important to understand the user requirement in full, the idea here is not to write loads of documents, especially when it comes to PHP projects. What is more important is to make sure that we model what the users require and, based on the models, get the users to provide feedback, and then improve the model based on the user feedback. Some simple techniques that can be used to capture requirements include:
- Studying the existing system
- Observation of the users in action in a real environment
- Interviews with potential users and stakeholders of the system
Some tools that can be used to capture requirements include:
- Data flow diagrams showing how data flows and processing happens in the system
- Use case diagrams that portray how potential users of the system would be using the system. When using use case diagrams, it is critical to capture all of the major use cases of the system at a high level. It does not need to be too detailed, but we need to ensure that we have not missed any key use case scenario in the implementation. We can always seek the help of the users to help us validate the use cases and fill in the gaps, in case we have missed any key user requirements.
When documenting user requirements, we need to be comprehensive, concise, and clear. This is because the team members need to be able to refer to those, whenever they want. If the requirement specifications are too bulky and take time to read, it might not help the team. Therefore, it is always a good idea to use diagrams and tables to summarize information, whenever possible, to make sure that the captured information can be grasped by the team members at a glance.
We need to make sure that the team members really refer to the requirements to during the project life cycle. Therefore, anything that encourages them to use those requirement specifications is welcome and would make the project's success more probable.
Modeling what the users want
The purpose of the requirements gathering activity is to help us understand what the users want. The next step is to come up with a model that bridges the gap between the real world and the software world. For example, we need to be able to map the user requirements to the data model, and the business logic model, that we can implement with the software technology that we know.
Data modeling activities are supposed to produce the data model that represents the data involved with the system under consideration. Entity relationship diagrams are the most well known tool to help model data in a system.
Note that modeling data is the first activity following the user requirement gathering. This depicts the importance of the data modeling activity with respect to the design and implementation of the rest of the system. Most of the systems are all about effective data storage processing and presenting.
The outcome of the data modeling activity is a set of diagrams that represent the entities within the system and their relationship to each other:
It is important to note that a data model is not the same as a database design. The model is the reference that can be used as the input to the database design activity, and the data model is also the input for the business modeling activity of the process. Data design will be explained later in this article.
Once we understand the data involved with the system, the next step is to understand the business activities carried out with those data. Business logic modeling can be done with tools such as data flow diagrams or use case diagrams. The objective is to understand what sort of business activities the users carry out with the software system being developed. The inputs and outputs of the business logic processing and the various data stores, where the data is pulled from, are modeled in this phase of the process. Like in the case of data modeling, we can validate the business model with the user and incorporate user feedback back into the model. It is also noteworthy that the business modeling activity is different from the business logic design activity. Business logic design is based on the business model that we develop in this phase of the process.
The output of the business modeling activity is the business model. Simply speaking, it is a set of diagrams that represent the use cases or the data flow. Like in the case of data model, the business model should also be simple to refer back, if team members require to do so.
Once we have both the data model and the business model, we can move on to the user activity analysis.
User activity analysis
While executing business functions with the software application, users engage in various activities using the system. Analyzing those activities becomes the next important activity in the process, and it also opens up the doors to understanding and designing the user interface.
Based on the business model and the data model, we can analyze the various activities that the users would want to carry out with the system. We can make use of the data processing functions of data flow diagrams, or use case diagrams, and come up with a list of user activities for each business use case of the system.
The list of user activities becomes the input for the storyboard design activity.
Before looking into the details of the presentation layer design, let us step back for a moment and look into data layer design.
Designs and implementing the data layer
The process model proposed in this article is intended to be used for PHP projects, and therefore, is based on the MVC pattern. The data layer represents the model in MVC. In the design of the PHP application, we need to first attend the data layer.
Using the data model as the input, we can perform data design. The data design can be independent from a specific database management system. However, the information, such as data types, needs to be taken into account. The number of tables, their relationships, the volume of data involved, and related performance implications need to be taken into account.
The next activity is the implementation, keeping open the option of switching the database management systems or supporting multiple database management systems open. In this activity, we might either use the database management systems directly or use SQL and try to be database agnostic. In addition to creating the database, the team members involved with the data layer implementation also devise plans for testing and also for carrying out unit testing.
In addition to SQL based unit testing, they need to implement the database access logic, which is also a part of the database layer, using PHP. The team members can then implement unit tests with PHP to verify the implementation. Executing the unit tests can be automated using PHP frameworks, upon each source code change.
Once the implementation is complete, it can be tested and verified completely using system testing by a quality assurance team.
Database implementation is a prerequisite for business logic implementation. However, business logic design need not wait until the database implementation is complete. As soon as data model is available, business modeling can be done and followed by business logic design. It is the business logic implementation that requires database implementation. The business layer sub-team can start its design work in parallel with the data layer sub-team and work side by side on their designs.
eBook Price: $20.99
Book Price: $34.99
Designs and implementing the business layer
Output from the business modeling activity is the input for the business logic design activity. The main objective is to design algorithms required to implement the kind of business logic that the users want the system to execute. We can use a natural language, as well as sequence diagrams, as tools in this phase. As PHP is close to natural language, we can use PHP in place of natural language for the business logic design. However, the risk here is that it can degenerate into coding activity. Therefore, it is advisable to use sequence diagrams and natural language, as per requirement, and only use PHP when it comes to the real implementation.
Business logic implementation is to implement the designed algorithms with PHP. We need to have the database access layer available for this phase. Unit testing can be done along the way to verify the implementation, the logic, algorithms, and the data processing. It is also welcome to automate the unit testing. This will verify the system to guard against regression when changes are done.
Implementation should carefully evaluate the need for the design and implementation of APIs. Also, the use of object-oriented features versus functional features of PHP should be evaluated. PHP code reuse, proper use of the PHP framework in place, as well as adhering to defined coding guidelines and best practices, must be given due attention in this phase of the process.
Once the implementation is done, system testing can be done to verify the implementation against the requirements. Note that we can start testing as soon as an independent module or a sub-system reaches completion in terms of implementation, without waiting for the entire system to complete. This way, we can make sure that issues are found earlier, and the development team as well as the testing team are kept busy all of the time.
Design and implementation of the user interface
The output of the user activity analysis is the input to the user interface design phase of the process. Business modeling is followed by the user activity modeling. User interface design can take place in parallel with the data design and business logic design. However, for the implementation of the user interface layer, the business logic implementation must be available.
The first activity in the user interface design is the design of the storyboards. It is a rule of thumb that, for each user activity, there will be a corresponding user interface element in the user interface. Therefore, we should have a storyboard for each user activity that we have identified.
Storyboard design can be done on a white board or with a pen or pencil and paper, with some rough sketches, to capture and model the user interface elements to support the user to interact with the system. The best practices, human computer interaction guidelines, as well as the consistency guidelines, should be taken into account in this phase of the process. We can get the storyboard designs reviewed by the users. Once we get the user feedback, and incorporate the feedback to the design, we have some agreement between the users and the team on the design. Then, we can move on to the next activity in the process, the prototyping phase.
With prototypes, we can convert the storyboards into an initial working model of the application. We can use PHP and HTML to get the job done in this phase. We can even make use of the PHP framework that we are using for the PHP project to build the prototype.
When building prototypes, there can be two modes of operation. One is to build the prototype to be thrown away later, to start on the real implementation from scratch. The other mode is to implement the prototype, so that it can be used later for the real implementation. Both modes have their own pros and cons. The throw away model reveals us the shortcomings in the design to us and helps us to fix those and come up with a better design later on. However, throw away models waste time, as we are working on something to be thrown away and that would not contribute to the final product. Prototyping with the objective of using that for the final product saves time. But the problem with that model is that a weakness in design of the prototype, if any, would be also inherited by the final implementation. With PHP, we can be flexible, and willing to throw away any bad designs, and in case the prototype is deemed to be good, use the same as the base for the final product.
The initial prototype can only focus on the layouts, without bothering with functionality and connecting that to the model or controller in MVC. Once we show that to the users and get their feedback, we can move on to a more detailed functional prototype implementation. That detailed implementation needs to make use of the business logic implementation and the database. Again, the idea of this functional prototype is to capture user feedback, and we must use the PHP framework that we plan to use for the project for this. Also note that given the time and effort that we are going to spend on the functional prototype, it would not be a good idea to throw this away. Therefore, we need to take some effort to make this as close to the real implementation as possible. If there are problems, we should fix these as early as possible. The functional prototype also needs to be run by the users and their feedback should be noted down and incorporated. One of the problems with the functional prototypes being evaluated by the users is that, because they are functional, the users might tend to mistake those with the final product. Therefore, it must be clearly communicated to the users and noted down that it is a prototype for evaluation purposes and not the final product by any means.
Once both the developers as well as the users, are happy about the prototype, we can move on to the final implementation of the presentation layer. As in the case of the implementation of the other layers, the developers can take care of the unit testing in this phase. There are tools that can automate web-based interface testing that the developers can make use of in this phase.
As and when modules are completed, those can be tested by the QA team.
The user interface sub-team of the PHP project team, can work closely with the business layer and data layer sub-team to make sure the success of the overall project. After all, it is a single project as far as the users are concerned, and for the product being developed to be useful, each part has to work with each other seamlessly.
In the this article, a process model, which can be used for PHP projects, was introduced. This process model is designed with the use of the MVC design pattern in the PHP projects.
This process model will be a very good starting point for your PHP projects. You should be able to improve it and customize it to suit your needs, when you gather more experience with the projects.
eBook Price: $20.99
Book Price: $34.99
About the Author :
Samisa Abeysinghe is Director, Engineering at WSO2. Samisa pioneered the Apache Axis2/C effort and architected the core of the Apache Axis2/C Web services engine. He continues to be an active contributor in the Apache Axis2/C project. His involvement in open-source projects began in 2004 when he started working with the Apache Axis C/C++ project.
Prior to his current role, Samisa played the project lead role for the WSO2 Web services Framework for PHP project, which provides comprehensive support for building both SOAP and REST services and clients.
Books From Packt