Guide to UML-assisted website planning and design (for the moment, diagrams are missing)

I. Overview
Websites are often complex and highly dynamic. To enable Web applications to run in a short time, the development cycle should be as short as possible. In many cases, developers directly enter the code writing phase, but do not carefully consider what kind of website they want to construct and how they are prepared to construct: server-side code is often written in an unprepared form, database tables are also on demand, and the entire application system sometimes shows a non-planned state. However, as long as we use some modeling and software engineering technologies, we can make the development process smoother and ensure that Web applications will be easier to maintain in the future.

UML (Unified Modeling Language) is a common visual Modeling Language used to describe, visualize, construct, and build software systems. UML is applicable to various software development methods, various stages of the software life cycle, various application fields, and various development tools. UML can describe the static structure and dynamic behavior of the system: the static structure defines the attributes and operations of important objects in the system and the relationships between these objects; dynamic behavior defines the time characteristics of the object and the mechanism by which the object communicates with each other to complete the target task. UML is not a programming language, but we can use a code generator to convert a UML model into multiple programming language code, or use a reverse generator tool to convert the program source code to a UML model.

This section describes how to use UML to build a Web site. Full use of UML Technology is a complex process, but some parts of UML are easy to use, and it can help you build a better system with less time.

To demonstrate the application of UML in website construction, this article constructs a website that supports wireless users and provides weather reports and traffic reports for various regions. This document does not describe UML in detail. For convenience, the appendix briefly introduces common UML symbols and terms. For more information about UML, see the reference resources at the end of this article.

II. Planning stage
Whether you are building a website from the beginning, porting a website, or adding an important feature, it is necessary to make some preliminary planning to ensure the optimization of design decisions. If you work with others to complete a project, it is immeasurable to reach a clear consensus on the total amount of work and its distribution. During the planning period, you should try to have a correct understanding of the following aspects of the system:

User and role.
Application requirements.
The conversion process between interfaces.
Tools and technologies to be used.

2.1 Users
It is important to understand the users who use the system. Not only does system analysis require you to have access to some users (through surveys, emails, or face-to-face conversations), but you also need to allow the system to control different user roles and permissions. By classifying users and understanding their needs, you can find clues to determine database security mechanisms, functional limitations, user interface groups, training and help needs, and specific content requirements, you can even learn about the distribution of potential advertisers.

Figure 1: Participant/role hierarchy

The figure above shows several different website users (called Actor in UML, that is, participants ). Here, the most common User type ("Site User") is located at the top of the graph, and the line arrow indicates the generalization relation ("generalization" relation, see The Appendix description in this article, the same below ), it indicates that the Site User can be divided into two types of users: Guest and Registered User. The features shared by these two types of users are described in Site User participants, while the selfish features of Guest and Registered users are described in the corresponding participants. Generally, you can add instructions directly to participants without having to write your own documents, but the specifics are related to your UML tools. In this example, Registered users can be subdivided into two types: Wireless User and Administrator. The system should handle these users differently.

2.2 define requirements
Before writing code, you should have a clear understanding of the system to be constructed. Although this work can be completed step by step while writing code, it is also very attractive, but the efficiency of collective discussion with graphics and text is much higher. It is often not that cost-effective to write detailed requirements for a website. However, you should have time to draw several sketches and write several annotations to describe the services the website is prepared to provide. This requires the Use Case diagram (Use Case diagram ). Use Case can be viewed as a set of functions-it may correspond to a page on the website, a required program, or an action that may occur on the website (for example, to verify user login, change the user's configuration file, clear expired accounts, and so on ). The following is a Use Case map that helps you plan your website. Note: This figure does not show all Use cases of the website. Generally, we need multiple Use Case diagrams to describe the complete website functions.

Figure 2: Use Case diagram

Even in such a simple Use Case diagram, we can easily express a large amount of information. For example, the include relationship indicates that two Use cases contain the same identity authentication function; extend relationship indicates that the weather page may be displayed in WML or HTML format; the generalization relationship indicates that each specific performance process follows the basic behavior rules described by "Render HTML Page" or "Render WML Page" to maintain a unified style effect and unify the macro behavior patterns. purpose.

The figure above also shows some areas that wireless users can access other users on the website. In this Use Case diagram, only wireless users can access traffic reports. This is because we have learned that only mobile users on the road need traffic reports, and we do not want to take the time to make traffic reports into other markup languages.