Struts Demand Analysis and Design

xiaoxiao2021-03-06  50

Methods for demand analysis and design for Struts applications, basically include the following steps:

1. Collect and analyze application needs

a. In this example, UML use case is used, which feels very clear such that it is very clear, but I don't know if I put it in front of me, but I go to analyze, I can do it. In short, after having a use case document, the code behind it is simply as simple as the wood.

b. The main contents of the use case document are: 1 pre-condition; 2 main event stream; 3 Other time flow; 4 post conditions

2. Designing the database, this life should be more important, I think it should be one of the factors that determine the performance performance!

3. Design the customer interface, these will be handed over to the art. Haha.

4. Design Actionform

5. Design Action

6. Design application business logic components

Here are some basic templates for use case documents

Document template:

System analysis report

1 Overview

1.1 Project Destination 1.2 Project Target 1.3 desired characteristics

2. System function design

2.1 Participants of the system can list the participants in the form of the table below

Participants define normal users to browse the contents of the knowledge base system, submit their interested knowledge administrators to review the contents of the article, add articles to the knowledge base ... ...... ......

2.2 Inventory, the following table forms can be used to list events.

Subject verb object arrival method Response normal user browsing article 1000 / day array hair browser Display User selected article administrator Add article 1 / day periodic in the database to save this article information ... ....................................... ... ...... ...............................................

2.3 case example

Use case

2.4 Example Description Each usage should have the following description:

Use Case Name: Skimming Use Case Description: This use case is responsible for displaying the user to complete the use cases of requests article: ××× participants (Actor): assuming that the average user: Users using a standard browser ...... Preconditions: postcondition: Main Path: Alternate Path: Abnormal Path:

2.5 Task steps for Main paths: ............

3. System architecture

Component to implement hardware: client based on P4 1.8G client, 128M memory ... hardware: server based on Dual CPU Xeon 3.2g 1G memory ... Software: Operating system (client) Windows 2000 Professional software: operating system (server) Windows 2000 Server Software: Applications (Client) Arbitrary Browser Software: Database Server Microsoft SQL Server 2000 Software: Web Server Microsoft IIS or Apache Tomcat ... Protocol: Network TCP / IP Protocol: Database JDBC-ODBC Bridge ... ... ...... ...... ......

Component map

Deployment diagram

4. Project planning

The function and time schedule of the first iteration of the first iteration; the function and time schedule of the second iteration of the products; the function and time schedule of the third iteration of products;

Concept of template explanation:

1.1 Project Purpose: Perform business causes of the project (such as sharing of knowledge).

1.2 Project Objectives: The project needs to be achieved in business. The project will bring about what benefits to the organization (such as systematic management of knowledge, facilitating knowledge, facilitating self-learning). 1.3 Required Features: Features must be supported by the project (such as browsing, addition, user management, etc.).

2.1 Participants: Invitation system in some form, and make it a role, usually people, but may also be other systems, timers, clocks, or hardware devices. Participants are required for the project to identify participants, in order to better understand the events that the project must support. Identifying participants are an important step in implementing the Actor in the example diagram. The corresponding participants can be found by the following questions:

l Who / What will be interested in this system?

l Who / What will I want to change the data in the system?

l Who / What does it need to establish an interface with the system?

l Who / What need to get information from the system?

2.2 Event List: List the system must pay attention to (or must handle) events, they will cause the system to react. At the same time, you should also specify the location of the event, the frequency, the way to arrive.

General Format of Event: Subject Verb Object

The subject is the previously defined participant, the verb is an operation that needs to be made, and the object is an object defined by the verb.

2.3 ~ 2.5 System use case: The use case description in this section is the most important part of the entire document, so detailed description, especially the main path, alternate path, and exception path of each use case.

Description: A brief description of the role of use case

Front conditions: The system must be in the system before performing the case, or the condition to be satisfied

Back conditions: Use case once the status is in the system

Main path: Describe the basic process of this use case, refers to things that occur when each process is "normal", without any preparational current and abnormal stream, and only the most likely event stream

Alternate path: It is an optional or alternative, which is not always necessary to perform them.

Abnormal path: means the flow of some abnormal things to be executed

For example: For the use of example, the space is limited, I only column here the knowledge content published in the background management system. as follows

Use case name: knowledge content release

Case Ligte: 202

Participant: administrator

Example description:

The administrator is used to upload the content of the corresponding directory, and the announcement finally appears on the responsive directory of the knowledge base.

Preconditions:

Administrator has logged in to the knowledge base management system

Principal path:

1. Administrators choose the corresponding directory

2. Administrator mouse click "Add Article" button

3. A text box and attachment upload button appears

4. Administrators can fill in the corresponding content in the text box

5. The administrator can click the browse button of the upload file to upload the corresponding attachment, or you can not upload accessories.

6. The administrator edited the text box and selected an attachment, press the "Submit" button, the database knowledge form, and the attachment table is modified according to the content of the text box.

7. Use case termination

Alternate path:

1. Before pressing the "Submit" button, the administrator can press the "Back" button, any modification of the text box content does not affect the content of the knowledge table in the database.

Abnormal path:

1. Tip error message, administrator confirmation

2. Return to the management system home page

Back conditions:

1. Added information on the corresponding catalog in the knowledge base

Note: None

转载请注明原文地址:https://www.9cbs.com/read-88244.html

New Post(0)