Using the [iconix] method to practice blog design 2 [case modeling]

Using the [iconix] method to practice blog design 2 [case modeling]

In the previous article, we learned about and implemented Domain Modeling. In other words, we had a good start, at least the developers
The software to be developed has a preliminary understanding and a glossary can be used for communication.
This chapter will further elaborate on the use of the iconix Method for practical case modeling in the previous article.
There are 10 mistakes that are most likely to be made at this stage to remind everyone or to make reference during the analysis process.
The position of this article in the iconix method is as follows (marked in red circles)

Before you start using case modeling, we need to have a rough understanding of this process.
The following content can be used as a review. If you have different opinions, you can also discuss them in the reply.
If the Domain Modeling is completed with a static model (such as an airplane model or car model ),
If the state model is actually dynamic, we need to start the dynamic model of system behavior (that is, the use case model) to note this model.
Input energy (whether it is gasoline or diesel ). The so-called dynamic model is an external-to-internal analysis method, while Domain Modeling is
Internal and external methods are used to analyze the system. I am glad to cite some original words in the book to explain this description:
The Domain Modeling Process is an internal/external method. It means that the process starts from the core object of the system and starts from the internal and external work.
How are these objects involved in the system to be constructed. Case-driven (the dynamic part of the model) is an internal and external method. This means
When you work in the direction from inside to outside and from outside to inside, you should make the two parts meet on the way, rather than making them not connected.
This is done when you perform robustness analysis and draw a sequence chart"
It seems that case modeling is the starting point of the entire driving (dynamic) process. This process is too important for system analysis.
Before starting the analysis, I hope you can look at the definition of the use case. This will guide the following analysis.
I use the definition of Ivar jacbson directly here: "The Use Case instance is a series of actions executed in the system, which will generate
A Use Case defines a group of use case instances as the value results visible to specific participants ". (Isn't it classic? Unfortunately, I just saw
What about Alibaba Cloud :)
In addition, we need to correct two common sense understandings:
1. the use case diagram is not equal to the use case model (because the use case model also includes the use case document)
2. Use Cases are used in the analysis phase rather than in the collection phase.
These two questions are believed to have been explained in similar articles in UML, so we will not explain them here.

Well, with the above introduction, I believe that friends who have used case modeling before or who have never touched UML will perform this chapter.
Practice has a rough idea. But how to perform case modeling is mainly divided into three steps:
1. identifying participants)
Participants act as everything that interacts with the system. They can also be other systems or hardware. It is not a system group
Components are objective and independent from the system. In fact, when determining the participants, you can ask questions, such as who is the department
Main users? Who gets information from the system, etc. As a software such as BLOG, participants are determined to facilitate analysis.
For users (or members and authors, once determined, the following use case description will use them like this ).
There is any fuzzy association between the user and the user list in. Here, the user and user list in the domain model is renamed as user information.
Information List. The other actor is the system administrator, and the system administrator in the previous domain model is renamed as the system administrator.
Administrator information.

2. Confirm the use case.
When determining use cases, the iconix method assumes that "you must first determine as many use cases as possible, and then constantly write and improve the descriptions of these use cases.
In this process, you will find new use cases and general situations ". The most important principle for determining a use case is its
It must be closely related to the materials in the user manual, and the relationship between each user and each part of the user guide must be obvious. Slave
The reason for the manual is that developers must "analyze and design the system from the user's perspective ". Because the manual content is generally very
Huge (related templates are obtained online), dozens or even hundreds of pages at will. The content required by this document must also be non-
This step is complex. Due to space limitations and concerns that everyone is away from the ideas in this article, only
Skip this step. You can find the relevant information on the Internet to fill in this blank. In addition, you can use the question Method to Identify use cases,
For example, what are the tasks of each participant? What input and output does the system need? (For details, see "Unified Modeling Language for system analyst Design Guide ").
In some books, merging requirements (mainly functional requirements, non-functional requirements can be attached to the use case description) are used to obtain and use
For example, the principle of merging is to generate a "visible result" (this step is because the operations are too complicated, this article
), And name the use case and draw the use case diagram. From my perspective, the two (iconix and other methods)
Is complementary and does not conflict with each other.
Use cases that have been preliminarily determined and sorted out are listed in the form of [verb (phrase)-noun (phrase)]:
Registered User (uc01), login System (uc02), Post article (uc03), edit article (uc04), delete Article (uc05 ),
Browse comments (uc07), delete comments (uc08), browse comments (uc09), delete comments (uc10), add links (uc11 ),
Edit Link (uc12), delete Link (uc13), Upload File (UC14), delete file (uc15), manage file type (uc16 ),
Edit the signature (uc17), edit the Personal Information (uc18), edit the basic blog information (uc19), and (Administrator) Review the user (uc20 ),
Create a club [or group] (uc21.
(The Administrator's basic functions are filtered out only as a secondary requirement. I hope you can understand this. Thus
Focus on the Design Analysis of iconix methods and use cases)
The following figure shows the use cases of the relevant Blog system (to prepare for the detailed use case document below ):

In fact, I want to point out a small mistake I have made before. I believe it is also a mistake that many friends may make without knowing it, that is, how to arrange it.
The level of the use case. For the iconix method, we recommend that you use a package to display the hierarchical structure. For example, you can manage the document (including several
For example, add, edit, or delete an article.) iconix uses a package to include these use cases, write the package name, and then
Plot the corresponding subgraph in the package. The main reasons for doing so are:
A logical boundary is provided for assigning work among development groups. One rule that can be followed is that each package corresponds to one or more of the user manuals.
At least one major section. The main purpose of using a large-range use case chart here is to easily describe the overall picture of the entire system, so that you can
The general examples only have a general understanding. We hope that you will weigh the weights in your actual work (when the number of use cases is large.
There are also three definitions of "case relationships" that need to be briefly described here:
Include(Included ):
It refers to the behavior of a use case that includes the behavior of another use case. This is a special dependency. That is, the close of "has"
System. See (manage the relationship between articles and publishing, edit, and delete articles)
Generation(General ):
A Use Case (subcase) inherits the behavior and meaning of another use case (parent case ).
The behaviors and meanings of use cases can also be added to cover the behaviors and meanings of the original use cases. For example
The relationship between "blog retrieval by author", "blog retrieval by content", and "blog retrieval. This relationship
It can be expressed by "is.
Extend(Extension ):
Similar to the general relationship, but there are more restrictions on extended use cases. For example, a use case is obviously mixed with two
Different scenarios, that is, a variety of things may occur. However, we can conclude that this use case is divided into a master use case and
Or multiple auxiliary use cases, which may be clearer.

Now, we need to refine the text of the case.

3. Refine the use case text.
First, start with user registration. Assume that the user text is as follows:

Case Name:Registered User (uc01)
Case document:
Basic Process:
Enter the user's name, password (twice), email address, and click "register. The system is verifying that the user has submitted information
Then, use the initial user information of the current data and record it to the user information list. Then the system prompts the user to wait for the System
System Administrator.

Branch process:
If the user does not provide a name, the system displays an error message notifying the user to enter the name.
If the email address format provided by the user is incorrect, the system displays an error message asking the user to enter the correct email address.
Address.
If the password entered twice is different, the system displays an error message indicating that the two passwords must be consistent.
If the user submitted by the user already exists in the user information list, the system tells the user and recommends that the user use another user name.

Some people may think that this step is too simple, because when we talk about it in many cases
Some UML books on how to describe the basic and branch processes of examples may provide reference rules.
For example:
1. Subject name, meaning easy to understand
2. Let readers know whether the participants are under control or the system is under control.
....

As the use case template in the iconix method, it has something to do with other UML methods or the use case templates recommended by many masters.
Different. It uses a 1040ez template. In other words, it mainly includes basic processes (basic event flows) and branch processes (extension tasks ).
File stream ). Unlike complex templates, it also requires content such as preconditions, post-conditions, non-functional requirements, extensions, and priorities. This method recognizes
For those things, they will not only distract themselves, but also waste valuable time.

As iconix, it recommends the following practices:
1. Create a simplified use case template (marked with "basic process" and "branch Process ")
2. Ask the question "What will happen" and proceed with the basic process.
3. Raise "what will happen next" and raise such questions until you get all the details about the basic process.
4. put forward "What will happen otherwise", is there any other situation? Are you sure? Raise these questions until they are recorded as large
The process of the bulk branch.
In short, this does not seek perfection, but considers the operations that the user may perform.
You can refer to these rules to see the above "registered users" to see if there is any other inspiration :)
In addition, the basic form of case text should be emphasized: Noun-Verb-Noun

"At the same time, if a new object is found in this process, the (problem) domain model should be updated to deepen the previous object discovery.
". (For example, we will find new objects in the next Use Case)

The following example shows three sub-cases of "Management articles". Here, we can see that it contains three sub-cases:
Table, edit, and delete articles, as described above. Its three sub-cases are the main functions of the system.

Case document:

Post (uc03)
Basic Process:
On the post page, enter the title, category (custom or system type), content, and whether to use abstract
Yes, whether to post (or put it in the draft box) and click Submit. After the system confirms that the information submitted in this article is valid,
Add the current data to the article list.

Branch process:
If the user does not have a title, the system displays an error message informing the user to enter the title of the article.
If the user provides the article content, the system displays an error message asking the user to enter the article content.
If the user publishes the abstract content but does not enter the abstract content, the system displays an error message asking the user to enter
Enter the abstract content.
If you want to go to another page when you have not completed the content of the current article, a warning message is displayed, prompting you to compile
Contents will be lost.
If the title of the article submitted by the user already exists in the article list, the system will tell the user and recommend that the user use another title.

Edit document (uc04)
Basic Process:
On the Edit Article Page, modify the title, category (custom or system type), content, and whether to use abstract
Yes, whether to post (or put it in the draft box) and click Submit. After the system confirms that the information submitted in this article is valid,
Use the current data to modify the corresponding article information in the document list.

Branch process:
If the user does not have a title, the system displays an error message informing the user to enter the title of the article.
If the user does not enter the content of the article, an error message is displayed, telling the user to enter the content of the article.
If the user publishes the abstract content but does not enter the abstract content, the system displays an error message asking the user to enter
Enter the abstract content.
If you want to go to another page when you have not completed the content of the current article, a warning message is displayed, prompting you to compile
Contents will be lost.
If the title of the article submitted by the user already exists in the article list, the system will tell the user and recommend that the user use another title.

Delete an article (uc05)
Basic Process:
After you click "delete" on the left of the corresponding article title on the article list page, the system prompts you whether to delete
After the user confirms the article, the corresponding article content in the article list will be deleted.

Branch process:
If you click "undelete" in the prompt box, the system will not perform any operations and redirect the page to the article column.
Table Page.

In the above three case texts, we mentioned that a new object is the article list, which I mentioned in the previous article
It is not added to the domain model. Because the system determines from the requirement that this object is required, we need to update the corresponding domain model.
:)

The following is an example of "File Management ".
Before talking about this use case, you need to explain some problems, that is, whether the use case itself needs to be divided into three sub-Use Cases (add,
Edit and delete) is more appropriate? However, in this case, three more use cases are added. If this happens
If the case is broken down, the number of use cases may be too large. This is also an issue that requires attention.
In the book, it is inevitable to talk about this issue, that is, "the granularity of case decomposition", because excessive decomposition will significantly increase the complexity, and
Too low may violate the principle of "visible value results" of the use case. If the use case of "managing the blog system" is too big
Use cases, there is no value to the user. The use case of "enter user name" is too small. It will be more appropriate to treat it as a step.
Well, the grasp of this "degree" is ultimately measured from the system (software) as a whole.
After talking about a lot of things, return to the current "file management type" case. In my opinion, it may be because of the user (document)
It is relatively simple, so we have merged the three so-called subcases into one. Of course, this is also benevolent, wise, wise, not
It is completely absolute. I hope you can give more comments at your discretion :)

Manage File Types (uc16)
Basic Process:
The system administrator enters the file type name (such as RAR and JPEG) in the "add file type" form (on the "file type list" Page)
), Type description, maximum upload size, upload path name, and other information. Then, click the submit button. After confirming that the information is valid,
Add the current data to the file type list.
On the file type list page, the system administrator clicks the delete button to check whether the file type is deleted.
After the Administrator confirms, the corresponding records are deleted from the file type list.
On the edit file type page, the system administrator modifies the corresponding type name, type description, maximum upload size, and corresponding path.
Click the update button. After confirming that this information is valid, the system uses the corresponding file type information in the current data modification type list.

Branch process:
If you have not entered the type name, maximum upload size, and the system prompts you to enter
Information.
If the type name submitted by the user already exists in the file type list, the system notifies the Administrator and recommends that the Administrator use another name.
Name.
If you click the delete button in the prompt box, the system will not perform any operations and redirect the page to "manage files ".
Type page.

Here, we also found that an object is the "file type list" and put it into the domain model :)
(I think you may have different opinions on this use case. You are welcome to discuss it in your reply .)

Other use case texts cannot be fully written due to my limited time. I will try my best to improve the content in the future.
Understanding. The practice of the iconix method must be discussed in this article. Therefore, we mainly need to use this method in case analysis.
And steps are the main purpose of writing this series of articles.

The last step is to list the ten most common case modeling errors. If you think that the error is not clear, let us know.
Tell me, I will put the corresponding explanation below for further discussion.

Ten Most common case modeling errors:
10. Write functional requirements instead of Application Scenario Text.
9. Describe attributes and methods instead of usage.
8. Writing use cases is too concise.
7. completely remove yourself from the user interface.
6. do not provide a clear name for the boundary object.
5. Do not write from the user's perspective and use the passive voice.
4. Only user interaction is described, and the system response is ignored.
3. The branch process text that does not describe the operation.
2. focus not on the case, but on how to arrive here or what will happen in the future.
1. Spend a month deciding whether to use the include or expand ).

Link for downloading the rose file: Use Case modeling (Rose file)
Final Statement: Due to my limited level and too many and complex knowledge points involved in this article, it is inevitable that there will be errors and errors in this article
I would like to express my sincere gratitude to my friends and experts in the garden :)

Keywords: iconix, UML, use case, use case, Oo, object-oriented, use case-driven.