Shulou(Shulou.com)06/03 Report--

First, the cause company gave me a task to write a mobile phone simulation interface for testers to facilitate their SMS testing. In the past, they used MC4J to directly call the MBean service of the company's server to simulate and test, in order to verify our entire system platform. The main purpose of this test is to check whether it is normal to send and receive text messages, and my job is to make them more convenient and intuitive during the test. Requirements I made an appointment with tester Chen MM (that is, the user of the software) to discuss the requirements of the software. 1. First of all, I got a general idea of their testing work and knew what I was going to do. 2. Then I went back and thought about it, asked her again to learn more about the specific steps of her testing, and recorded the required functions in the form of a UML use case diagram on a blank piece of paper. What is the use case? The use case is the requirement, which is the function your software should have, of course, the use case diagram is only a general description of the function. Finally, I sat in front of my computer and started using MagicDraw UML to draw use case diagrams (I don't like to use Rose, it's too bulky and the interface is not friendly). When drawing use case diagrams, I found some implicit features that Chen MM did not take into account when making requirements with me. Chen MM and I identified these newly discovered requirements one by one and ended up with the following use case diagram. (1) use case diagram for the test operation of the phone's foreground (note: include means that a use case contains (include) sub-use cases)

(2) background management

Third, interface design is followed by interface design. Since it is a mobile phone simulation, I naturally use the interface of my motorola phone as a reference. However, it should be noted here that the operating environment of the mobile phone is different from that of the computer (for example, the computer has a mouse and a keyboard can enter text), so there is no need for a perfect simulation, but mainly based on the convenience of the user. Interface design is a very important step, do not write the program as soon as you come up, you must first have a general idea in mind, otherwise there is a great possibility of rework. Moreover, by showing the interface to the customer, the customer can have a clear idea and put forward some new needs and opinions as soon as possible. Do not wait until the software is finished before showing it to the customer. If the customer wants to modify it, it will be too much wasted work. Due to the relatively simple interface of the software, Chen MM basically did not propose any changes, but this is not a good sign. But extreme programming is about embracing change, not ^ _ ^. We are not afraid of her to change, as long as she can decide on the general interface. I like to use Visio to draw interfaces. Of course, I have heard that some people like to use VB to quickly build interface prototypes, depending on their personal preferences. The whole interface is as follows:

This is the background management interface.

Fourth, the class diagram reflects the data model of the software. In designing the data model, I refer to the interface design diagram and use case diagram to find out the classes one by one. Then, with reference to the functions of the use case diagram, various properties and methods are designed. Of course, it is impossible to design the initial class diagram in detail, but you should at least see a rough picture. It doesn't matter if there is a mistake, it can be corrected slowly later, but the general relationship is settled. Neil (company CTO, a real senior programmer in his 40s) said: looking at the design of a software mainly depends on two classes: class diagram and sequence diagram. The class diagram determines the static relationship of the software data model, and the timing diagram is the dynamic relationship of the data model. The class diagram is as follows, you can roughly know the meaning and function of the class / attribute / method in English, so we won't introduce them one by one.

The timing diagram is the last diagram in this paper, which not only shows the realization scheme of each function in the use case diagram, but also reflects the interaction of all kinds in the class diagram. After that, the logic of the program is basically the same as the sequence diagram. However, some people will draw very detailed timing diagrams, so detailed that they can almost catch up with the pseudo-code level, which I don't think is necessary. I think of the sequence chart as a general process that reflects my thoughts, so I just draw a rough picture. I think the sequence diagram should be concise and easy to understand, so that after your successor maintainer gets the sequence diagram of the software (including use case diagram and class diagram, of course), you can understand your general design idea. In addition, drawing time sequence diagrams can also sort out their own ideas, and at the same time, they can also verify the design of class diagrams. In the process of drawing this sequence diagram, I corrected several inconsiderate points in the class diagram. Summary: the sequence diagram can (1) organize ideas (2) verify the design of the class (3) is a good software document and is very helpful for maintainers to understand the code. Only a few of the timing diagrams are given here (in fact, I didn't draw all the use cases, and some similar simple ones were ignored. (1) add a mobile phone number

(2) shutdown

(3) turn it on

(4) send SMS messages

At this point, the design phase is completed, and it takes one day. The next step is coding, which will be written in the same way that TDD writes the test code first.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.