UML for website development

UML and website development.

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   Displays several sets of 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. It also shows that wireless users can access some areas that other users cannot access. 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. Therefore, the "get traffic report" use case does not need to be divided into two display formats: WML and HTML. It can directly include the "render WML traffic report" Use Case. Generally, you should add a simple description for these use cases. Specifically, you should describe what will happen in each use case, who can use it, how it starts, how it stops, and some special events that may occur in some cases (called variation, changes ). 　　2.3 User Interface Organization In the process of making use case, you will get some clues indicating which user interfaces the website needs. Maybe you have a good idea for designing some pages long ago, but use case helps us look at the problem from another perspective. Do users really need so many interfaces? Is a page too complex? Is the website's navigation facilities easy to use, that is, is it convenient to access common services from the home page? You should solve these problems in the use case diagram before sketching the interface and making the website prototype. When use case becomes clearer, we can start to outline the general structure of the website. Some people will emphasize that pages and files should be modeled using the corresponding component diagram (Component digraphs). In fact, the class diagram tool is also very convenient. See:   Figure 3: user interface and Layout   In, various website services are bound to different website regions:   /-Website Root /Common/-Common Graphics, scripts, CSS files, etc. /Maps/-map data /Traffic/-traffic flow report /Weather/-weather report   The figure also shows the parameters passed between pages. Regionid is a very important parameter. It represents the region (probably a country, city, or province) that the user is interested in ). Regionid transmits region information between pages so that you can jump to traffic flow information from the weather report of the specified region. As for the common area of the website, you can see that the Pointer Points to the entire package instead of a single file in the region, which is a simplified method to reduce confusion, because most (if not all) files in the/common/region are used for all other packages. The User Interface layout can help you avoid website chaos. It is useful for Website planning. In addition, once an effective website structure organization method is determined, it can also be applied on multiple websites as a fixed mode.     　　2.4 select Tools For small websites, the selection of tools and technologies is quite simple. Especially because of investment, only a few tool groups have practical significance-Apache, MySQL, PostgreSQL, PHP, Perl, or JSP/servlet. Currently, the most popular combination is Apache + PHP + MySQL, which has many low-price web hosting service support and is mainly concentrated on this tool combination. For a large website, it must perform more rigorous evaluation and testing on various tools before investing in application software. The following is an example of a component diagram, which can be used to describe the website architecture. This figure is simple, but it already describes the architecture of most websites. It may not be necessary to recreate the image for your website, because there is no difference in the content that deserves to be added to this image.   Figure 4: website architecture Diagram   The entire life cycle of the software has exceeded the scope of this article, but it should be pointed out that the establishment of the application prototype and interface model should begin at this time. Be sure to write down some ideas about the website structure and page layout, because you will eventually want to write some common code for the layout (menu, navigation bar, overall page layout, etc. In addition, if you are switching to new tools and technologies, the prototype building work will allow you to ensure the feasibility of the design, make sure that you have provided sufficient training for developers on the use of new tools. 　　Iii. Design Phase The design phase should overlap with the analysis phase. Once you have a lot of knowledge about the system you want to build, you should start to develop design ideas. It is meaningless to first analyze the system 100% and then enter the design stage. The demand is always evolving, and the design itself sometimes drives the development of the demand (and vice versa ). All developers are performing some type of design-but some developers are directly designing in the form of programming code. Although this can also accomplish the task, it makes it very difficult to manage complex projects and assign tasks within the Working Group. Take a moment to build a system model through a design drawing, and you will get a huge return in the future. 　　Design for the future in 3.1 Many developers spend more time debugging and rewriting code than coding. If we look at the problem from the construction of more than one website, the situation is particularly serious. A good website design can be applied to multiple websites in the form of structure, organization, and code reuse. However, if the code is just piled up in a rush, the chance to benefit from the existing code for a long time will be reduced. A very effective way to design and plan a website is to draw a class digram ). Shows many important relationships that are commonly used in class diagrams.   Figure 5: class diagram   Description:       The Renderer class is an abstract class (displayed in italics ). This means that the Renderer class cannot be used directly. The program can only create instances (new region () of its subclass ()). To display page content to different types of browsers, all pages used to generate content must be derived from the Renderer class.     The weatherreport class creates and has a region object, which is displayed by a black diamond representing aggregate relationship. It indicates that an object owns and creates other objects.     The plus sign ("+") before the method name indicates that the method is a public method and can be called by other objects or functions. The minus sign ("-") indicates that the method or variable is private, it can only be accessed by member functions within the same object. In PHP, Chinese methods and variables are common, but we should always treat variables as private to avoid direct access to variables from outside the object.     The htmlweatherreport class depends on the htmlutils class. Dependency indicates that a class needs to create an instance of another class or call a method of another class.     Each class in the class diagram should indicate: all methods (and all variables, if any), method access attributes (public, private, or protected), method return value type, method parameter, the type of the variable. The function is written in front. If the class has variables, they are generally listed in a separate box.   Even if you are not constructing an object-oriented system, you can still use class diagrams to create a system model. Class can easily describe various inclusion relationships and function files you have written. Although the class chart does not show the unique relationships of the inheritance, composition, and aggregation object-oriented systems, it can describe the call relationships between files using dependencies. 　　3.2 System Model during running In some cases, we need to show how each part of the application completes the task collaboratively at runtime. The preceding class diagram shows the relationship between classes, but it does not show the order of calls, nor the result from a function may determine the target of the next call. To describe the system on a more dynamic level, UML provides many other types of diagrams. Scenario digraphs are particularly useful for Web website design. A plot is divided into two types: A collaboration diagram and a sequence diagram ). Generally, we do not create a model for all the interaction processes of the system. The plot is only used to describe the most complex part of the system, or to summarize the general call mode of the Code. For example, we may want to demonstrate how a specific page works with code that authenticates a user's identity, or display how the page calls public code (tool-based framework code) to maintain a uniform appearance and style. The collaboration diagram and sequence diagram are as follows.   Figure 6: Collaboration Diagram   The preceding collaboration diagram shows the general process of obtaining weather reports from a web site. Note that this figure ignores some unimportant methods, because we are only interested in the key steps in the process. You can find the execution order of each function from "1" to "1.3.3.4. Some people prefer "1, 2, 3 ,......" Indicates the number of the execution step, but in general, "1, 1.1, 1.2, 2, 2.1,…" is used ,......" It is a better choice to show the call stack depth. This numbering method can clearly display the program's control conversion process. For example, the report () method calls many methods in wmlutil and region objects: Before using a series of query and content generation functions to generate reports for a specified region, we called buildheader (...) in wmlutil (...) function. Finally, we call buildfooter (...) of the wmlutil module (...), then return the report () method and getpage (). You can add more details to the collaboration diagram, such as the return value, constraints, and conditions.   Figure 7: sequence diagram   In terms of the information transmitted by the image, the sequence diagram and the collaborative plot are very similar. In fact, many UML modeling tools can generate order diagrams from collaboration diagrams, or vice versa. The main difference between a sequence chart and a collaboration chart is that the order of events in the sequence chart is clear and intuitive. In addition, detailed information about the lifecycle and time can be added to the sequence diagram, such as latency, thread concurrency, Object Construction and deletion. When deciding whether to select a sequence chart or a collaboration chart, consider the following points to help you make the most appropriate choice:   If you want to display issues that are closely related to time or thread in the code, select the sequence chart. If you want to display the interaction mode between objects, select a collaboration diagram. If you want to display the interaction process between several or a large number of objects, select the order chart. If you want to display a large number of message transmission or interaction processes between a small number of objects, select the collaboration diagram.     　　3.3 Application Deployment Plan As mentioned in the "tool selection" section above, the architecture of most web sites is not complex. Even so, deployment digraphs are still useful in two aspects: website structure and file organization. For file organizations, it has been mentioned in the previous discussion about interface planning that can also be planned using class modeling tools. The following is a simple component Diagram for your reference. However, you may not need a simple component Diagram Based on your website's needs and complexity.   Figure 8: component Diagram   　　3.4 Design Principles UML is just a tool. If this method is used, UML can help us easily construct a better website. However, to design a good website, the key is to have a good design principle or philosophy. "Increasing the cohesion of classes and reducing the connections between different classes" is often cited repeatedly when it comes to good object-oriented design principles. An cohesive class contains behaviors and information closely related to the target and scope. It means that you should not mix the code that constructs the UI and the code that implements mathematical algorithms. You should try your best to encapsulate all user-related information into the useraccount class. Cohesion design is an important design principle for many reasons: it helps reduce the dependency between classes, making the design more intuitive and easier to understand, it facilitates introducing the entire design to other developers, reducing the number of classes that developers need to operate at the same time, and so on. For example, if you want to change the website's user authentication mechanism, modifying only one class in a single file is undoubtedly more convenient than modifying multiple files and classes. "Reducing connections between different classes" means minimizing interactions between classes or files. It not only makes the entire design easy to understand, but also facilitates code maintenance. Consider the following example:   Figure 9: design instance   It is impossible to estimate the degree of cohesion of these classes unless you have a deep understanding of the usage of these classes. However, from the relationship between these classes, we can see that this design scheme has successfully reduced the relationship between different classes. The interactions between classes are minimized, making the system behavior easy to understand. More importantly, the number of affected classes is minimized when any class is modified (for example, modifying Class D only directly affects Class B ). In addition, to access functions in Class D, we do not need to know anything about Class E, F, or G. For comparison, consider:   Figure 10 design instance B   Obviously, in this design instance, the relationships between classes are quite close. Once the D1 class is modified, in order to check the impact of this modification on other classes, we must perform extensive tests on other classes. You can avoid overly complex design only when you exercise constantly in practice, but pay attention to the following points to help achieve this goal:   Improve the cohesion of the class. Do not scatter closely related functions into multiple files and classes. Use intuitive and meaningful names. If others cannot understand the functions of classes, functions, or variables, no matter how perfect the class structure is, the entire design still lacks intuition. Too many acronyms will affect the comprehensibility of the design. Do not be afraid to rewrite the code. Sometimes moving some functions between several classes can greatly simplify the code. Class should be compact and concise. Code expansion is a sign of a lack of cohesion in the class. A class, module, or file that is too large often lacks clear purposes and objectives. Let others review your design. Others may have new ideas, or point out the problems that you think are obvious but cannot be understood by others. Do not consider too many performance issues in the early design phase. Compared to a clumsy design optimized for yesterday's problems, a concise and well-adjusted design makes performance optimization easier. Note that it is not recommended to leave the performance issue behind, but to leave the problem of detail optimization to be considered later in the project. Iv. UML tools The following are some UML modeling tools worth considering:   Microsoft Visio: Visio Professional 2000 now provides built-in UML support. It is a very valuable tool to consider other uses of the Visio drawing tool. If you use a version earlier than 2000, you can find the Visio stencel and template for UML here. Rational Rose: This is a recommended tool, but it is expensive for many small web projects. With tools like Rational Rose, it is easy to improve and maintain the design, generate reports from models, and work with others in a parallel collaboration environment. Magicdraw: a cheap Java-based UML modeling tool. Together: it is closely related to C/C ++ and Java and supports UML modeling. Objecteering UML: a free personal UML product. System impact ect: a popular high-end UML modeling tool that supports round-trip engineering ).   V. Appendix: Common UML Symbols and reference resources The following table briefly describes common UML Symbols and relationships. For more information about UML concepts and various object-oriented terms, see references.   Symbol Description Package Package. Used to aggregate and organize a part of the model (Use Case, class, and so on ). Actor Participants. It represents a user or other external drivers. Use Case Use Cases. Use Case describes the behavior of a part of the system. Generally, use case records requirements for a system function, which is demonstrated by responses to actions or events. <> Relationship Include link. The Use Case relationship marked as <> link can introduce other use case functions. This is a convenient way to separate use cases and avoid a single use case that is too large. <> Relationship Expand the relationship. When the use case relationship marked as <> relationship does not repeat the descriptions and requirements of the existing use case, the behavior of the existing use case can be specialized. Dependency Dependency. As its literal meaning, it indicates that one thing depends on another thing. This means that one thing understands another thing and needs another thing to function. Note Annotation. The purpose of providing annotations in a UML diagram is to briefly describe the content of the chart. Component Component. A component generally represents a software unit. It may be a DLL, an execution file, or a database. Node Node. A node generally represents a machine that can run one or more system components. Class Class. Classes in UML are the same as classes in Object-Oriented Programming, that is, they define and encapsulate a group of behaviors and attributes. Class is instantiated at runtime to create an object. Object Object. The object is a class instance. For example, "myclass myobj = new myclass;" creates a myobj object. Generalization Generalization. The parent class can be derived from (or called Special) subclasses with more special behaviors. In this case, the parent class is the super class of the subclass (or the generalized version of the subclass ). Interface Interface. Interface defines a group of behaviors that can be accessed from outside. Classes, libraries, execution files, and data files can all be described by interfaces. The interface itself does not implement any function, but it only enters into a contract with the object that declares that the interface is implemented with which actions must be implemented. Abstract class Abstract class. Abstract classes cannot be directly instantiated, but can be derived from specific classes with actual functions. Association Association. Association is to connect two or more classes. You can provide more specific information for the relationship between two classes. Association is the relationship between two or more specific class elements. It describes the connection between these class elements. In an association, the same class can appear in multiple locations. Aggregation Aggregation. The aggregation relationship indicates that an object belongs to another object.