The Road to OO System Designer - Analysis Model Series (1) - What is an Analysis Model?

xitong

The Road to OO System Designer - Analysis Model Series (1) - What is an Analysis Model? [Copy link]

The analysis model is the product of implementing use case scenarios using analysis classes within the constraints of the system architecture and framework.

The analysis model is a high-level system view. Semantically, the analysis class does not represent the final implementation. It is a high-level abstraction of computer system elements.

The author believes that the analysis model is the core of OO design, and the design class is only a means of implementing OO.

The analysis model is a classic application of the MVC pattern. By comparing the name of the analysis class and the MVC pattern, readers should be able to find the subtle correspondence between the analysis class in OO and business goals: people, things, objects, rules - actor, boundary, engagement, control . This is why the author says that the analysis model is the core of OO design.

(Friends who are interested in the OO Road series have waited for a long time. Today, we officially launch the second part of the Road series, the OO System Designer Road. In the first part, the OO System Analyst Road, we started with what is a use case and ended with the requirements specification. We still remember that in the first part, the final result was the system use case. The system use case specifies the scope of the system, and through the use case scenario, it specifies the system blueprint, so that we know how the system will implement the business specified in the business use case. These tasks are completed by the system analyst. Up to now, we still don’t know how to let the computer perform these businesses. Everyone knows that after the requirements process is over, the next step is the analysis and design process, which is the responsibility of the system designer. The second part of the OO Road is aimed at system designers. In the following articles, the author will try to explain how to do system design, what tools to use, what results to produce, and how to verify whether our design is correct.

This is the first article of the designer's journey. I will discuss analysis models. We often hear the term analysis model, but few people really understand or have used analysis models. Below I will write a conversation that simulates the conversations I had with many candidates during the process of recruiting designers. More than 90% of the candidates cannot answer these questions well. Readers can also try to answer them to see how deep your understanding of OO system design with UML is.

Dialogue scene:

-After the requirements process is over, what will you do next?
-Analysis and design

-What is the basis for your design?
-Requirement results, use case model

-How did you design? What was the result of the design?
-Design class diagrams, determine the methods and properties of the class, and use sequence diagrams to express the interactions between classes. Also, apply design patterns to enhance the scalability and reuse capabilities of the system.

-How do you determine the classes? For example, for a specific requirement, why do you decide to use three classes instead of five? How do you determine the class methods? Why design seven methods instead of ten?
-After a short silence: Experience, from my design experience and actual situation in multiple projects, using these classes and these methods can fully meet business requirements, and they are optimized and are the best solution.

-Then how can you guarantee, or what can you use to prove that your design can meet the requirements? In addition to experience, what other methods can you use to prove it?
-After silence: I have rich design experience, and my design is well thought out. The design will be reviewed, discussed and fully communicated, and then tested. If it does not meet the requirements, it will be modified and supplemented.

-Just now you said that you will carry out analysis and design after the requirements are completed. Can you explain the difference between analysis and design? What does analysis do and what does design do?
-Longer silence: Analysis and design are the same process. Analysis is the process of thinking, and design is to express the content of thinking with classes.

-We know that there are analysis models and design models in UML. If analysis and design are the same process, can you tell us the difference between analysis models and design models?
-Silence...

Yes, it is true. Many people cannot distinguish the different goals of analysis and design, and have never used or do not know the analysis model. Even more people cannot answer how their design can be proven to meet the needs. In their view, those classes are based on experience, like elves jumping out of their minds. They are very confident in their experience and design ability, and they are happy to talk about one design pattern after another. They think, how can such an excellent design not meet the needs? Proof? It is a very strange question. The purpose of my design is to meet the needs. If the design does not meet the needs, I will continue to improve it. In the end, it must meet the needs.

Unfortunately, this does not answer my question. What I asked is how to prove it, not whether it is satisfied. Even if the designer has rich experience and super design ability, and the design result does meet the requirements and is excellent, it is only the result, not the process. It is the victory of a personal hero, not the victory of the software process.

In fact, all these problems are just because designers forget a very important process, the analysis model. So what is the analysis model? Why can the analysis model solve these problems?

The definition of analysis model and analysis class in RUP is: Analysis classes are used to obtain the main "responsibility clusters" in the system. They represent the prototype classes of the system and are the "first pass" of the main abstract concepts that the system must deal with. If you want to obtain a "high-level" conceptual summary of the system, you can maintain the analysis class itself. Analysis classes can also generate the main abstractions of system design: the system's design classes and subsystems.

If you are confused by the above definition (RUP's definition has always been like this), the following is the author's understanding and application experience of the analysis model in actual work, which may help readers sort out the ideas.

• The analysis model is the product of using analysis classes to implement use case scenarios under the constraints of system architecture and framework. In the first part of the OO road, we said that use cases and use case scenarios define the business scope and requirements. If the analysis class fully implements these use cases and scenarios, we can definitely say that the analysis class has met the requirements.

  What are analysis classes? Generally speaking, analysis classes are:

  Boundary

  
  Entity

  

  Control

  

  Plus the actor classes needed to implement the use case scenarios , there are four in total. These analysis classes will be discussed in detail in later articles, and readers only need to remember what they look like now.

• The analysis model is a high-level system view. In terms of semantics, the analysis class does not represent the final implementation. It is a high-level abstraction of computer system elements. The above four analysis classes can completely simulate the execution process of the computer. After the analysis class is concretized, the real implementation class is generated, which is the so-called design class, which is what most designers call a class diagram.

• I believe that the analysis model is the core of OO design, and the design class is just the means of implementing OO. Do you remember the three levels of reuse mentioned in the first part of the previous article? Component-level reuse is actually expressed through the analysis model, while reuse in the design model only uses the characteristics of the OO language to achieve the requirements of reuse.

• The analysis model is a classic application of the MVC pattern. This can be seen from the name of the analysis class. In the fourth part of the previous book, the author talked about a point of view: "No matter how complex a business system is, no matter what industry it is in, its essence is nothing more than people, things, objects, and rules. People are the center of everything. People do things, things produce objects, and rules restrict people and things. People drive the system, things reflect the process, objects record the results, and rules are control. Whether it is OO or UML, under the complex surface is actually just a simple rule. System analysts figure out who there are, what people do, what things produce what objects, and what rules are in between, and then define the relationship between people, things, and objects, and business modeling is basically completed." According to this paragraph, and then compare the name of the analysis class, think about the MVC pattern, readers should be able to find the exquisite correspondence between the analysis class in OO and business goals: people, things, objects, rules-- actor, boundary, engagement, control . This is why the author said that the analysis model is the core of OO design.

The question is why do we need analysis models? Most systems are not built using analysis models, but they still work. And in RUP, analysis models are only an optional process, not a mandatory process.

Indeed, this is probably why most designers do not use analysis models. However, at the same time, the problem in the conversation scenario at the beginning of the article also arises. Some readers may ask, you said that the analysis model fully implements the use case scenario and can therefore prove that the design meets the requirements, then I use the design class to implement the use case scenario, can't I also prove it in the same way? Then what is the use of the analysis model?

This is exactly why the analysis model exists. As I said earlier, the analysis class does not represent the implementation. It is only after it is concretized into the design class that it is implemented. The analysis class is a high-level abstraction of system elements. Experienced designers, especially those who are good at using design patterns, know that if an OO system wants to maintain its scalability and reusability, and to control the impact of changes within a small range, it is necessary to apply high-level abstraction and use high-level abstract interfaces to express system behavior, while delaying the specific implementation to subclasses, configuration documents, and even runtime. All design patterns, no matter what techniques are used, are for these purposes. The analysis model also continues this idea for system design, using four highly abstract analysis classes to express system behavior, and delaying the implementation to the design class. These abstractions are transparent to the implementation method and the implementation language. The core ideas it expresses are system architecture, business implementation patterns and specifications, and traceable verification of requirements.

For example, we use an entity analysis class to express a business entity. In the analysis model, we define all the interactions and access operations for the entity. For the level of abstraction of the analysis model, the simulation implementation of the computer system for the business requirements has been fully expressed. But in fact, the business requirements are not really implemented at this time. Until it is concretized into a design class, according to the development language characteristics, framework, specifications and other requirements, this entity analysis class can be concretized into one or more SDOs, POJOs, EntityBeans, and can use Hibernate, Webshpere BO, Weblogic XMLbean... and so on. The implementation method and language can be determined according to actual needs, so the implementation can be delayed, which brings the potential for OO expansion and reuse. And at this time, the designer no longer needs to worry about whether the concretized design classes will deviate from the requirements. They have been verified at the analysis model level, and can concentrate on considering the characteristics required for system implementation. In subsequent articles, the author will discuss these issues in more detail. Here is just an example.

Why should we use analysis classes instead of design classes to verify requirements? This is because the level of abstraction is higher, and the workload and possible changes of analysis classes are much less than those of design classes. For example, for login requirements, if we use analysis classes to express them, we only need to send a login request to the login control class. However, since design classes are related to the implementation method and have been concretized to the implementation, the login method and method are different according to different security verification methods, such as LDAP, CA, SSL, or different application servers, and there may be many steps, such as getUser(), getRole(), getGroup(), register()... Are you willing to use so many instructions to indicate that a simple login requirement has been verified? Wait, what if the security mode is changed? What if the application server is changed? This is also very common in real situations. For analysis classes, since the level of abstraction is higher than the implementation method, they continue to be valid, while design classes must be changed. This is one of the reasons why analysis models should be used to verify requirements.

A serious reader may say that if the security model changes, even if it is not for verifying requirements, the design class itself has to be changed. Doesn't this seem to have any inevitable causal relationship? Consider that in a project team, when a design document is shared with the development team responsible for each module, each team has formed a common understanding of the document. If this understanding is based on the analysis model rather than the design model, when the security model changes, the development team responsible for the security module can change the design class it is responsible for without notifying other teams. Because from the level of the analysis model, nothing has changed. This is the same as the familiar design class that changes the class implementation while keeping the interface unchanged. As long as the interface remains unchanged, there is no need to notify anyone. If this consensus is based on the design model, every small change needs to be notified to each team, because the understanding of each team is based on the class name and method name. If it is changed, can it not notify others? From an OO perspective, this is the difference between loose coupling and tight coupling.

From the above examples, we can see that the analysis model is much more stable than the design model, so it is good to use it to verify and express the mapping from system to requirements. This helps to keep the mapping from system to requirements stable during the development process when the implementation class changes, one class changes to two, and suddenly a design pattern is added (this situation is very common, right?), and at the same time maintain a stable system view and business architecture. For the development team, these changes will not affect their understanding of the overall system.

The higher level of abstraction of the analysis model helps people understand the system behavior more easily. Since it is independent of the implementation, the system interaction process can be expressed in plain language. For example, for login requirements, we can directly use "login()" to represent this system request. Compared with method names such as getUser(), getRole(), getGroup() in the design class, the analysis model is obviously much more straightforward. And developers' good understanding of system behavior will obviously be of great help to development. In a complex project with horizontal cooperation among multiple teams, the analysis model is more effective. Because of its simplicity and stability, it will reduce the cost of detailed communication for each development team.

Finally, if the project you are working on is not a one-off project, but is based on an industry, with similar or identical orders, and you plan to stay in this industry for a long time, do it in depth, and form a complete industry solution, then the analysis model must be considered. When your organization faces different customers in the same industry, it may not be possible to guarantee that all customers choose the same language, the same software platform, and have the same business requirements. At the level of the design model, this will inevitably lead to many different implementation versions. Faced with so many different versions, how to maintain a "unified industry solution"? As mentioned above, since the abstract level of the analysis model is higher than the implementation method and implementation language, you can use the analysis model to maintain this solution. Still using the login example, although some customers may use LDAP, some use CA, and there may be new models in the future, for the analysis model, the security module can always be consistent. This will be very conducive to the gradual maintenance of the analysis model as each project proceeds, and form a unified, stable architecture and industry solution, and different implementation packages can be provided for different customer requirements.

This is the first article on the road to becoming an OO system designer. The author discussed what an analysis model is and why we should use it. The next article will use an example to illustrate how to use an analysis model and what its results are. Stay tuned.

mdreamj

Very good series, thank you