< eight > Analytical class of UML core elements for object-oriented analysis

A: Basic concepts
----> In that large number of projects, the analysis class is a very useful element that is overlooked.
----> Analysis classes are used to obtain the primary "responsibility clusters" in the system, which represent the prototype classes of the system and are the "first gates" of the main abstractions that the system has to deal with. If you expect to get the "advanced" conceptual brief of the system, you can maintain the analysis class itself, and the analysis class can also produce the main abstraction of the system design-the design classes and subsystems of the system.
Second: The nature of the analysis class
-----> Analysis class represents the main "responsibility cluster" in the system, which means that the analysis class is the "First gate" in the process of transforming from functional requirement to computer.
-----> Analysis classes can produce system design classes and subsystems, which means that computer implementations can be produced in a way that is not captured by the head.
Three: The model of the analysis class, is the class type
"1" Boundary class

----> Boundary classes are classes used to model the interaction between the external environment of the system and the internal workings.
Boundary classes should be established between---> participants and use Cases
---> If there is interaction between the use case and the use case, a boundary class should be established for it.
(1) One use case if you want to access another use case, direct access to the internal object of the use case is a bad structure, which will lead to tight coupling, and the boundary class can be a direct access to gree, which acts as a façade pattern. At the end of the implementation, the boundary class between the use cases can evolve into a set of APIs, a set of JMS messages, or a set of proxy classes.
---> If a use case interacts with a non-human object outside the system boundary, such as a third-party system, a boundary class should be established for it.
(1) This is usually due to heterogeneous systems, heterogeneous data, access rights, security channels and other reasons. In concrete implementations, boundary classes can evolve into mediations and communication protocols. Examples of mediations such as gateways, communication middleware, proxy servers, security authentication servers, Webservice,soa components. Examples of communication protocols such as HTTP,FTP,SSL,RMI,SOAP, etc.
----> have distinct independence requirements in the associated business objects, they may develop and change in their respective fields, but they also want to establish boundary classes for them when they do not wish to influence each other.
----> From an architectural standpoint, the boundary class is mainly located in the presentation layer. The acquisition of boundary classes has important guiding significance for the presentation layer in architecture design.
A good boundary class should have the following characteristics:
(1) The boundary class should have a subject to improve the usability of the system
(2) Boundary classes should be kept to a higher level (e.g. conceptual level) as much as possible
(3) The boundary class should reasonably encapsulate the interaction between the system and the protagonist.
(4) If the protagonist changes the way they provide input to the system, the boundary class should be the only object that needs to be changed.
(5) The boundary class should be the only object that needs to be changed if the system changes to the way the protagonist provides the output.
(6) The boundary class must "know" the requirements of other object types (such as control objects and entity objects) so that they can be implemented, and the availability and validity of the "internal elements of the system" newspaper

"2" Control class

-----> Control Classes Model The control behavior that is unique to one or several use cases. Control objects (instances of control classes) typically control other objects. Because they behave in a coordinated nature. The control class encapsulates the unique behavior of a use case
-----> Control classes derive from the definition of behavior in a use case scenario, in other words, the control class derives from the analysis and definition of verbs in a use case scenario, including the limitation of verb descriptions.
---> For example, we have mentioned the use case scenario where the sender sent a letter to the post office. The scenario is described as: The sender arrives at the post office, buys an envelope, letters the envelope, addresses, weighs, calculates postage, buys stamps, stamps, mails, and takes receipts. In this scenario, the act of buying, loading, writing, calculating, buying, pasting, mailing can be the source of the control class.
----> When extracting a control class, carefully examine the behavior in the use case scenario, and if these behaviors have similar characteristics in the execution of steps, execution requirements, or execution results, you should consider appropriate abstractions. For example, merging or extracting super classes. At the same time, we should also examine whether these behaviors have an impact on the system to be built and then make some trade-offs. For example, the above scene, loading, writing, paste on the behavior is the sender's artificial behavior, will not affect the letter system, and thus can be shed.
----> in the definition of UML, the control class is considered as the main role of the coordinate object. For example, the entity class is accessed from the boundary class through the control class. or the entity class accesses another entity class through the control class. But the definition of UML also argues that it is not necessary to enforce the use of control classes, such as boundary classes, which can also directly access entity classes.


"3" entity class

----> Entity classes are classes that are used to model the information that must be stored and the related behavior. Entity objects (instances of entity classes) are used to save and update information about some phenomena. For example, an event, a person, or some real-life object. Entity classes are usually permanent. The attributes and relationships they have are long-term needs. Sometimes even the entire lifetime of the system is needed.
----> Entity classes originate from business entities in the business model.

Four: three-height analysis class
----> Analysis classes are the most important elements in the transformation process from business requirements to system design. They abstract the system at a high level to realize the prototype of the business requirements. The business requirements are logically interpreted by the analysis classes and become the semantics that can be understood by the computer. The abstract hierarchy of analysis classes has three high characteristics, precisely because of these characteristics, so that the analysis of the class is more than the design class "better use" element, but also the author likes to use the analysis of the most important reason. The three heights of the analysis class are:

< eight > Analytical class of UML core elements for object-oriented analysis