Chapter 2 system modeling process

Part 4 System Modeling Process

Chapter 2 Overview

Compared with traditional process-oriented software engineering, object-oriented software engineering has great differences in demand acquisition, system analysis, design, and implementation. UML is a common tool for OOA and OOD. The process of building Object-Oriented Software Engineering for software using UML is a process of continuously refined modeling of the system. These models include case models, analysis models, and design models. Then, we need to use a specific computer language to establish a system implementation model. Of course, in the entire software project, we also need to establish a system test model to ensure the quality of software products.

If you use an object-oriented tool to build a system, you should use an object-oriented software engineering method. However, we often find that, in the actual development process, although many developers can understand all the diagrams of UML, they still cannot use UML to build the entire project with ease, the major reason is that the original software engineering method is still in use, but it is not clear how to use UML to establish these models of the system, and the difference between analysis and design is not clear, and the conversion between them.

In essence, application software systems are digital simulation of the real world using computers. According to the UML method, the manufacturing process of application software is the process of establishing these column models. This document describes how to use UML to model a library system.

The basic requirement for this library system is that students can borrow and return books in the library. In addition, they can also access and Book Reservation through the Internet or library terminal. Of course, the library administrator can also manage books. In order to simplify the system, we have not subdivided the personnel in the library.

This relatively simple case is used because many people have a strong perceptual knowledge of the library system. In this way, readers do not need to spend a lot of time understanding the business knowledge contained in the system. At the same time, this article only discusses the process of using UML, focuses on the process of using UML for modeling, describes the differences and links between models at various levels, and shows the process of system evolution, without going into the details of UML. For more complex systems, the analysis and design methods are the same.

Chapter 1 case model-acquisition of system requirements

The Use Case model defines what the system does and is an effective means to obtain system requirements. The Use Case Model consists of "role" and "use case. When building a use case, the first thing we usually need to do is to identify roles, or participants. Then we need to identify the service provided by the system for the participants, or the behavior of the participants, that is, the use case. Finally, we determine the relationship between the role and the use case. In this library system, we can identify the roles of students and librarians. The entire use case model includes the following use cases: borrowing books, returning books, reading books, booking books, and maintaining books. The Use Case model can be represented as follows using the example diagram:

The key to determining a valid use case is to check whether the use case contains a complete function. Use cases cannot be too detailed, and a part of a complete function cannot be used as a use case, nor can a use case contain too many functions. For example, user logon. When booking a book, students may need to log on to the system first, which is a function of the system. However, this function is only a step in the book's complete function, or a sub-function, and is not suitable for making a use case. On the other hand, both borrowing and Returning books are relatively complete functions. If you combine these two use cases into a use case similar to "processing books, obviously, we cannot clearly express the meaning of the use case.

Description case

It is important to understand that using UML for system modeling does not only mean drawing UML diagrams. To learn UML, you must not only learn UML graphics, but also learn the corresponding document description methods.

When describing a use case, we can use text to describe the case, or other graphs to describe the case, such as sequence or activity diagrams. The following describes the complete structure of the use cases recommended in the RUP:

WName. The name should undoubtedly indicate the user's intention or use case, for example, "enrollment in research classes ". WIdentifier [Optional]. A unique identifier, such as UC1701, can be used to reference this use case in other elements of a project (such as a class model. WDescription. The following is an overview of the use case. WParticipants [Optional]. List of participants related to this use case. Although this information is included in the use case itself, it helps increase understanding of the use case when there is no use case diagram. WStatus [Optional]. Indicates the status of the use case, typically in progress, waiting for review, passed review, or not passed review. WFrequency. ParticipantsAccessThe frequency of this case. This is a free question, for example, once a user accesses each record or once a month. WPrerequisites. A list of conditions that must be met before the access case. WPost Condition. A list of conditions. If conditions are included in the List, these conditions are met after the use case is completed successfully. WExtended use cases [Optional]. The extended use case of this use case (if any ). Extended Association is a generalized relationship in which the extended use case is followed by the behavior of the base use case. This is achieved by inserting an additional operation sequence into the operation sequence of the base case through the extension case. This is always modeled using the use case association with <extend>. WIncluded use cases [Optional]. This use case contains a list of use cases. Include Association is a generalized relationship that indicates the include relationship of the behavior described in the case in another use case. This is always modeled using the use case association with <include>. Also knownUseOrWith(Has-)Link. WSuppose [Optional]. Any important assumptions about the domain created when writing this case. You should test these assumptions at a certain time, or make them part of the decision, or add them to the basic or optional process of the operation. WBasic Procedure. The main logical path that the participant follows in the use case. Because it describes how the use case works when all work is normal, it is usually calledProper path(Happy path)OrMaster path(Main path). WOptional procedure. The logical paths rarely used in the use case, which are observed when the work mode is changed, an exception occurs, or an error occurs. WModify history [Optional]. Detailed information about the modification time, reason, and modifier of the use case. WQuestion [Optional]. If yes, it is a list of issues related to the development of this case or the operation items. WDecision Making. A list of key decisions. These decisions are generally made by your SME and are the content of the use case. Record these decisions for maintenanceGroup memory(Group memory)Is very important.

Next, we will describe the use case of borrowing books:

Name: Borrow Books ".

Description: After selecting the desired books in the library, the students borrow the books from the librarians.

Participants: Student, Librarians

Frequency: There may be multiple times a day. The busiest case is that there are a lot of people borrowing books. At the current speed, about one person finishes his work every minute.

Prerequisites: None

Post Condition: Modify the remaining number of books lent.

Hypothesis:The borrower always finds books from the library before he can take the books for the borrowing procedures. Therefore, there is always enough books to lend.

Basic Procedure: The book is successfully borrowed.

1) The student will hand over the borrowed books and debit cards to the Librarians

2) the librarians enter the student's borrow card number and the borrowed book into the system.

3) The system proofreads the borrowing information and compares the previous borrowing and current borrowing situations of the student. If no borrowing is allowed, the information of the borrowing transaction is recorded, modify the number of books in the collection.

4) if the student has already subscribed to The Book, cancel the reservation.

5) Report the transaction success.

Optional procedure: The maximum number of books borrowed is exceeded.

1) The student will hand over the borrowed books and debit cards to the Librarians

2) the librarians enter the student's borrow card number and the borrowed book into the system.

3) The system proofreads the borrow information and compares the previous and current borrow information of the student. If the maximum number of borrowed books has been exceeded, the current transaction is stopped and the cause of the error is prompted.

4) the librarians can reduce the number of books borrowed and resubmit them to the system based on the students' opinions.

Flow activity diagram:See figure 1.

 

Figure 1: Borrow Books

Problem:None.

Decision Making: Omitted.

In the preceding section, we provide a detailed description of this use case. Step by step, we can gradually complete the use case model of the entire system.

Once again, the use of UML modeling, document description and graphics are equally important, and you must use the UML method to compile documents.

Chapter 3 analysis model-developer's vision

In the process of system analysis, we are still concerned about the problem. However, unlike the case model, the case model looks at the problem from the end user's perspective, the analysis model describes the problem from the developer's perspective. The main task of the case model is to describe the business processes in the real world, but seldom involves the concept of a system. The analysis is to look at the services that the software should provide to users from the perspective of the system. Similarly, different from the design, analysis remains at the "what to do" level ,. But the design needs to solve the "how to solve the problem ".

The selection of development languages and other technologies is generally not considered in the analysis model. The analysis model is implemented independently, which can provide maximum reuse and help developers to learn the technical details too early, in this way, we can clarify our ideas from a more general perspective.

Static Model Creation

The first step for analysis and modeling is to identify the object and then extract the class. Considering the famous MVC pattern, we need to identify three objects: entity, control, and border. It is a good practice to provide guidance for identifying objects in the MVC mode. The result of object recognition is the static model we need. It is usually represented as a class chart.

First, we can identify entity objects. These objects are usually obvious, such as the roles in the system and the materials to be processed by the system, such as the books and materials to be processed in the system; some entity objects need to be analyzed a little before they can be obtained. For example, in this system, we may need an object to record this information in order to record the information borrowed from books. These objects are called Modal (entity class ).

Then we need to identify the business logic objects required to complete the business logic of the system and the interface classes for interaction with users. In the MVC mode, they correspond to the Control class respectively) and View (Boundary class ). In the analysis phase, these objects are generally organized in a more natural way. For example, to complete a business function, we usually need a control class and a boundary class to control the class to execute the business logic, the boundary class interacts with the customer. Of course, this is not absolute. After further in-depth analysis, these classes may be broken down and merged.

A single bite cannot eat all the meals. The same is true for system analysis. We need to use one case for analysis. Now, let's first analyze the use case of borrowing books.

In this example, we can first identify some direct objects, including BookAdmin, Student, and Book, we will find that we need an object to record the borrow and return information of the book (BorrowInfo ). Finally, we found that, during the course of borrowing books, we will use the information (SubscribrInfo) of the book ). In this step, we have basically completed object recognition. Then, we found that we needed a control class (Borrow) for borrowing books and a user interface (BorrowInterface) to accept users' input. In this way, we can establish a preliminary model.

 

Figure 2: Borrow Books

In the analysis model, we also need to identify some attributes and methods of the class. Similarly, in order to avoid getting into details too early and adapt to future class changes during design, we generally only identify some main attributes and methods in the analysis model. For example, for the Student class, we only need the Name and CardNo attributes. For the Book, we only need the BooKID, AllCount (total number of books), CurrentCount (current number). Now, we can add the above attributes for our class graph to get the following results:

 

Figure 3: Borrow Books

However, after all these attributes are marked, it is difficult to deploy the images. Due to the layout of the article, attributes are usually hidden in future text unless necessary, so that they will look neat.

Based on the examples, after we analyze the use cases of Returning books, reading books, booking books, and managing books, we can get the static analysis model of the entire system.

Of course, we need to further sort out and analyze this preliminary model. class diagrams will change and there will be some relationships between classes. We may also use some analysis modes to further optimize our analysis results. For more information about Analysis Models, see Analysis Patterns -- Reusable Object Models by Martin Fowler. We will not discuss it further here.

Dynamic Model Creation

In an object-oriented system, business flows are represented by interactions between objects. With the objects analyzed above, we can describe how they interact and collaborate. In UML, we can use sequence diagram, activity diagram, or state diagram to model these dynamic processes. Similarly, let's first look at the use case of borrowing books.

In the use case of borrowing books, there are two event streams: successful borrowing of books (normal event streams) and the amount of books borrowed exceeds the maximum amount of books borrowed (abnormal event streams ). We will first create the event stream "successful borrowing". The following figure shows the sequence of the event stream:

In the analysis process, message transmission may be different or less rigorous than the subsequent design model and implementation model. For example, in the Borrow process, the BorrowInfo action is recorded, it may not be recorded by the BorrowInfo entity class itself (there is often an entity runtime class to complete this function, such as PersistanceManager in JDO, which depends on the specific technical framework you adopt). However, here, we can transmit the message in this way, indicating that this information needs to be recorded.

Similarly, we can also create a sequence chart for "the number of books borrowed exceeds the maximum number of books borrowed". This figure is relatively simple:

Similarly, we can create a dynamic model for other event streams in other use cases. Here we will not draw them one by one.

The creation of dynamic and static models is an interactive process. When creating a dynamic model, we will find some new classes and find some new attributes and methods for the existing classes. In this way, we will need to modify our class diagram. And vice versa.

After the analysis model is complete, we have a complete and clear understanding of the functions to be completed by the system. Below, we can start our design work.

Chapter 4 system design-Implementation Plan

The design is a detailed description of the system. We need to provide detailed solutions here. Similar to the tools used for analysis, you also need to create static and dynamic models, which are also represented by class diagrams, sequence diagrams, collaboration diagrams, activity diagrams, and state diagrams.

Before the formal design, we still have some work to complete, that is, to choose our technical solutions, which will affect our design.

Technology Selection-work before Design

The design is designed for the implementation of services, and the technologies to be used during implementation will affect the adoption of the design scheme. The following technical issues need to be considered:

What kind of client is u ready to use?

What programming language is u going to adopt?

What framework technology is u going to adopt?

If u is a distributed system, what communication mechanism is used?

In this library system, we found that for borrowing and Returning books, it always happens inside the Library, and the number of clients is limited, which is frequently used, efficiency and ease of use need to be considered, and the maintenance workload of the client software is relatively small, you do not need to consider too much, so we are ready to use the traditional Windows Form client. However, for reading and booking books, we hope to provide this function throughout the campus network so that students can use this function wherever they are, we will consider using a Web browser client to facilitate system deployment. That is to say, our system needs to support two non-customers at the same time. Obviously, it is a good solution to use the N-layer system structure to concentrate the system logic on the application server. Finally, for system security, we hope to separate Web servers from application servers. In this way, the topology of our system architecture is basically as follows:

 

This is a typical distributed system. After considering various platforms and technologies, we decided to use EJB technology to build this system, he has provided us with an excellent technical framework required to build an application system. At the same time, I want to call the client and application server, use the Web Service method (test the new technology :)). For Windows Form clients, we use Java to create a Windows application. For Web clients, JSP technology is used.

Of course, you can also use Microsoft. net platform and C # language to complete this work, but because Microsoft is in. the. Net platform does not yet provide an application system framework as mature as J2EE or JDO. Therefore, you must design this framework by yourself. In this regard, the monks have also designed their own Websharp framework, which may help you omit this work. For the content of Websharp, refer to the object-oriented application service layer design by idea.

In this way, our decisions on specific technologies are basically complete, and we can start to design them. Of course, there may be a lot of details to be done in the actual project, such as system conventions and design specifications, but this is not the content discussed in this article.

Design package or subsystem

First, we need to divide the system. Because our system is an N-layer distributed system that includes the application server and client, and the client also contains the Windows Form client and Web client, we first divide the system into three packages: Application Server, Winform customer, and Web Customer:

Because our system contains five use cases, each of which is a complete sub-system, we can divide the three packages into five sub-packages. However, here, because the system is relatively simple and the functions to be completed in each use case are relatively simple, we should further divide them here.

Design Application Server

Next, we will first design the application server section. We still start to design this case by borrowing books.

From the analysis model, we know that a control class is needed to complete the business logic of borrowing books. Here, we design a BorrowLogic class to complete this function. This class is designed as SessionBean. At the same time, because we need to provide services to the client, and we do not want to directly expose the business logic to the client, we design the BorrowServer Web Service to provide services to the client. In this way, the Borrow class in the analysis model is mapped to the BorrowLogic and BorrowServer classes.

Similarly, we need the Book class to record the information of the Book, Student to identify the Student, and BorrowInfo and SubscribeInfo to record the borrowing and Book Reservation respectively. In this way, the classes required to establish the static model in the design model are basically complete. Of course, at the final stage, we need to add complete attributes and methods for these classes. These entity classes are finally designed as EntityBean.

The entire design model of this part looks like this:

Then, we will design his dynamic model for the successful event stream. We still use the sequence diagram to represent it.

Design the client

Now, we design the client for the event stream of successful borrowing. The client is relatively simple here. He needs an interface to accept the input, and then sends the borrow request to BorrowServer through a BorrowServer client. We design this class as BorrowClient. The class diagram is as follows:

The Sequent diagram can be expressed as follows:

In this way, we have completed his design for the use case of borrowing books. Based on the gourd plot, we can design other use cases. Of course, in the design process, we may adopt some skills to make our design more flexible and reasonable. This is the optimization of the system design. The best book about this is the design pattern written by the famous four-person gang.

The final work of the design is to complete the database work according to the designed object model, and give the ing relationship between the object and the database. This is not the question to be discussed in this article. In addition, in a sense, the database design is actually the work that needs to be done to implement the model. It is part of the work that implements our design. This concept is similar to the original design method. The main task of the design work is to design the database. It cannot be said that it is a challenge.

We can see that for the same use case, a model in the analysis model is split into two parts in the design model. In this case, in the analysis, we are still concerned with the logic of the system. In the design, we must provide solutions to implement these logics, including the system architecture, system deployment, and application distribution. A class in the analysis model may be mapped into two classes in the design model. Of course, it may also be mapped into a class in the design for multiple types of analysis. We need to pay attention to the different focuses and differences of analysis and design.

Implementation Model -- construct our system

For model implementation, the work is very clear, that is, the design model is converted into the ability to run program code. This work is what all our programmers do every day, therefore, this article is not intended to be discussed too much. One thing to note is that, just like the transformation from an analysis model to a design model, some changes will also occur during the conversion from the design model to the implementation model, which is normal.

Conclusion

Using UML to model a system is actually a very natural process. As long as we follow the established reasonable steps, adopt reasonable methods, and perform in-depth analysis step by step, we can complete our tasks well. In this article, we use a simple system to demonstrate such basic steps and methods, and to demonstrate the relationship between different points of each model and each other, as well as their transformation and evolution processes, we hope to inspire and help you in designing more complex systems.