Three types of analysis classes in the 20151015_ system analysis phase

　　In the system analysis phase, the analysis classes are divided into three types: entity class, Interface class, control class.

1. Entity Classes

Entity classes are primarily a category of data management and business logic processing, and their primary responsibility for differentiating entity classes in the analysis phase is to store and manage information inside the system, and it can have behavior or even complex behavior, but these behaviors must be closely related to the entity objects it represents

Basic information

The definition of the entity class given above is more abstract. Classes have inheritance and recursion, and entity classes can further define specific classes based on abstract classes

An entity class is a class that is 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, such as events, people, or some real-life objects. Entity classes are usually permanent, and they have properties and relationships that are needed for a long time, sometimes even throughout the lifetime of the system.

An entity object is typically not unique to a use case implementation; sometimes an entity object is not even dedicated to the system itself. The values of their properties and relationships are usually specified by the protagonist. You may also want to use entity objects when performing internal system tasks. The behavior of an entity object can be as complex as the behavior of other object stereotypes. However, unlike other objects, this behavior is strongly correlated with the phenomenon represented by the entity object. Entity objects are independent of the environment (lead).

Entity objects represent the core concepts of a system in development. Typical examples of entity classes in a banking system are accounts and customers. In a network processing system, the typical examples are nodes and links.

If the phenomenon you want to model is not used by other classes, you can model it as an attribute of an entity class, or even as a relationship between entity classes. On the other hand, if the phenomenon is used by other classes in the design model, you must model it as a class.

Entity classes provide an alternative perspective for understanding the system, because entity classes display logical data structures that help you understand what the system should provide to users.

Find entity classes

Entity classes represent information stores in systems that are typically used to represent core concepts managed by the system. Entity objects are often passive and permanent. Their primary responsibility is to store and manage information in the system.

We are often looking for entity classes from glossaries (in the requirements phase) and business domain models (if business modeling is established in the business modeling phase).

Entity class restrictions

An entity class should only have an association relationship with other entity classes. The lifetime of an entity class object is generally long, while the lifetime of the control class object and the Boundary class object is short. It is because the lifetimes of these classes differ so much that it is undesirable to establish an association between these classes.

It is recommended to use the association between different class stereotypes.

* Replace with a "subscription" association to control certain events in the class subscription entity class object in this association relationship.

Promote consistency

1 • After discovering a new behavior, check whether the existing classes have similar responsibilities. Reuse existing classes whenever possible. Create a new class only if there is a lack of existing objects that can execute the new behavior.  2  · After the class is determined, the classes are checked to ensure that their responsibilities are consistent. If the responsibilities of a class are unrelated, the object is divided into two or more classes. The collaboration diagram should also be updated accordingly.  3  · If a class is divided due to unrelated responsibilities, check the collaboration that the class participates in and determine if the collaboration needs to be updated. If necessary, you can update this collaboration.  4 · There is no problem with a class with only one duty, but the necessity of its existence is itself questionable. Always be prepared to challenge and validate the existence of all classes.

2. Control class

The control class is used to describe the event flow control behavior of a use case and to control the sequence of events in a use case.

Basic information

The control class is used to model the control behavior that is unique to one or several use cases. Control objects (instances of control classes) typically control other objects, so their behavior is coordinated. The control class encapsulates the unique behavior of the use case.

The behavior of the control object is closely related to the implementation of a particular use case. In many scenarios, you can even say that the control object "grasps" the implementation of the use case. However, if the use case tasks are closely related, some control objects can participate in multiple use case implementations. In addition, multiple control objects of different control classes can participate in the same use case. Not all use cases require control objects. For example, if the event flow of a use case is related to an entity object, then the bounding object may implement the use case with the assistance of that entity object. You can identify a control class for each use case implementation first, and then refine it after you have identified more use-case implementations and found more commonality.

Because the control class can represent the dynamic behavior of the system and handle the main tasks and control flows, they can help to understand the system.

When the system executes the use case, it produces a control object. Control objects often die out after they have finished executing the application.

　　Note : The control class does not handle everything that a use case needs to do. Instead, it coordinates the activities of other objects that are used to implement this function. The control class delegates the work to an object that has been assigned the responsibility for this feature.

Find control classes

The control class is used to coordinate behavior in the system. The system can execute certain use cases without controlling the object (using only entity objects and boundary objects), especially those that simply process the stored information.

More complex use cases generally require one or more control classes to coordinate the behavior of other objects in the system. Examples of control objects are the transaction manager, resource coordinator, and error handler.

The control class effectively separates the boundary object from the entity object, making the system more adaptable to changes that occur within its boundaries. These control classes also separate the behavior specific to the use case from the entity object, making the entity objects more reusable in use cases and systems.

The behavior provided by the control class has the following characteristics:

· Independent of the environment (not changed with the change of environment). Determine the control logic (sequence of events) and transactions in the use case. In the case of changes in the internal structure or behavior of the entity class, there will be little change. The content of several entity classes is used or specified, so the behavior of these entity classes needs to be reconciled. It is not performed the same way each time it is activated (the event stream has multiple states).

Additional Information

The event flow of a use case determines the order in which different tasks are executed. First, investigate whether the flow of events can be handled by defined boundary classes and entity classes. For simple event streams that are primarily for entering, retrieving, displaying, or modifying information, it is often not necessary to use a single control class, which is the boundary class that coordinates the use case.

If the event flow is complex and contains dynamic behavior that may change independently of the interface (boundary Class) or the Repository (entity Class), then the event stream should be encapsulated in a separate control class. By encapsulating the event stream, the same control class can be reused by various systems with different interfaces and repositories (or at least the underlying data structures).

Example: Managing Task queues

You can identify a control class from the execution task case of the warehouse management system. The control class processes a task queue to ensure that the task is executed in the correct order. Once the transport tool is assigned, it executes the next task in the queue. Therefore, the system can perform multiple tasks at the same time.

If the behavior defined by its corresponding control object is divided into two control classes (Task performer and Queue Handler), it is easier to describe this behavior. The queue Handler object will handle only the order of queues and the allocation of transport tools. The entire queue requires only one queue Handler object. Once the system is performing a task, it produces a new task performer object to perform the task. Therefore, each task performed by the system requires a task performer object.

Complex classes should be divided according to similar duties

The main benefit of this division is that we separate the queue processing responsibilities (the responsibilities of many use cases) from the unique activities of task management, which are unique to the use case. This makes understanding the class easier and easier to modify as the design matures. This also helps to maintain the load balance of the system, because as long as there is a need to handle the load, you can create enough Task performer to handle the workload.

Encapsulates the main event stream and the alternate/exception event flow in separate control classes in order to simplify the change, encapsulating the primary and alternate event streams in different control classes. If the stream of alternative events and the exception event flow are completely independent, then they are also separated. This facilitates future extension and maintenance of the system.

If the two protagonists share the same control class, then the control class should be divided if multiple protagonists use the same control class, then the control class may also need to be divided. In this way, we isolate the change of a protagonist's needs from the rest of the system. If the cost of the change is high, or the consequences are very serious, you should identify and divide all the control classes that are related to multiple protagonists. Ideally, each control class should interact with at most one lead (through some boundary objects).

Example: Phone Call management

Take the example of a local phone call. We first identify a control class to manage the call.

The control classes used to control local calls in telephone systems can be quickly divided into two control classes: A behavior and B behavior, respectively, corresponding to the respective protagonists.

In the local call, there are two main characters: a user who dials the phone and the B user who answers the call. A the user picks up the microphone, hears the dial tone, and dials the phone number. The system immediately stores the number and analyzes it. When the system receives all the numbers, it sends the ringing tone to the A user and sends a ringing signal to the B user. B when the user picks up the microphone, the ringing and ringing signals stop, and the calls between the two users can begin. The call stops until all two users hang up.

There are two types of behaviors that must be controlled: A client-side behavior and B-client behavior. For this reason, the initial control object is divided into two control objects: A behavior and B behavior.

You do not have to divide the control class if:

· You have reason to believe that the behavior of the protagonist associated with the control class object will never change or be minimal.

· Controlling the behavior of an object in a class is fundamentally irrelevant to the behavior of one of the protagonists, and a single object can contain all behaviors. The effect of the behavior combination in this way on the change can be negligible.

3. Boundary class

The analysis class is divided into three types during the system Analysis phase: Entity class, Boundary class, control class

Boundary classes are used to describe interactions between external actors and systems. Identifying boundary classes can help developers identify the user's needs for the interface.

A boundary class is a class that is used to model the interaction between the external environment of the system and its internal workings. This interaction involves converting events and documenting changes in the system representations (such as interfaces).

Boundary classes model The parts of the system that are dependent on the environment. Entity classes and Control classes model the part that is independent of the system's external environment. Therefore, if you change the GUI or the communication protocol, only the boundary classes will be changed, with no effect on the entity class and the control class.

By defining the boundaries of the system, boundary classes help people to understand the system more easily. At design time, they provide a good starting point for determining related services. For example, if a printer interface is identified at the beginning of the design, you will soon find that you must also model the format of the printout.

Common boundary classes are windows, communication protocols, printer interfaces, sensors, and terminals. If you are using the GUI Builder, you do not have to model regular interface parts, such as buttons, as separate boundary classes. Typically, the entire window is the most refined boundary class object. Boundary classes also help to obtain interfaces that may not target any object's APIs, such as legacy code.

You should model the boundary class based on the boundary type represented by the boundary class. Communication with other systems and communication with the lead (through the user interface) are quite different in purpose. In user interface modeling, the most interesting thing to see is how to display the interface to the user. In the system communication modeling, the most concern is the communication protocol.

The lifetime of a boundary object (that is, an instance of a boundary class) can be longer than the lifetime of a use case instance. For example, the boundary object must appear on the screen for a period of time between the execution of the two use cases to match this situation. However, they typically have a long lifetime.

The Find boundary class boundary class helps the system interface interact with the outside of the system. The boundary object separates the system from its external environment (changes to the interfaces of other systems, changes in user requirements, and so on) so that these changes do not affect other parts of the system.

A system may have multiple boundary classes:

1 · User interface Classes- classes that help communicate with system users
2 · System interface Classes- classes that help communicate with other systems
3 · Device interface Classes-classes that provide interfaces for devices used to monitor external events, such as sensors

　　Find User Interface Classes

The boundary classes that represent the user interface may exist during the user interface modeling activity, and can be reused for the duration of this activity as long as appropriate. If user interface modeling has not been done, the following discussion will help you find these classes.

There is at least one boundary class for each use case lead pair. It can be assumed that this object is responsible for coordinating the interaction with the protagonists. This boundary object has some helper objects, and the bounding object delegates some of its responsibilities to these helper objects. This is especially true for window-based GUI applications. In these applications, typically each window or form corresponds to a boundary class.

Create sketches of user interface prototypes or screen dumps to show the behavior and appearance of boundary objects.

Model only the core part of the system, and do not model every button, list, and widget in the GUI. The purpose of the analysis is to get a general idea of how the system is constituted, not to design every nuance. In other words, you only need to determine the boundary class for some phenomena in the system or some of the things mentioned in the event flow implemented by the use case. See also Guide: Boundary Class (User interface Modeling).

The boundary class that looks for the system interface class to communicate with the external system is responsible for managing the conversation with the external system, which provides an interface with the external system for the system being built.

Example:

In an ATM, withdrawals must be verified through an ATM network (a protagonist), which is then verified by the bank accounting system. We can identify an object that is called an ATM network interface to provide communication with the ATM network.

Interfaces with existing systems may already be clearly defined. If so, responsibilities can be deduced directly from the interface definition. If you already have a formal interface definition, you can reverse engineer it, so you don't have to formally define it here. Just note that the existing interface will be reused in the design phase.

Find the behavior of some elements in a device interface class system so that they look like external elements (which spontaneously change values without being affected by any object in the system), such as sensor devices. While it is possible to use the protagonist to represent such external devices, the system user finds that doing so creates some "confusion", as this is likely to result in "equating" to the device and the real person. However, once we no longer collect requirements, we need to consider the sources of all external events and ensure that we have a way to let the system detect these events.

If you are using a lead to represent a device in a use case model, it is easy to verify that the use of boundary classes to help devices communicate with the system is justified. If these "device leads" are not available in the use case model, it is time to add them and update the use-case supplemental instructions where appropriate.

Create a boundary class for each "device lead" to get the responsibility of the device or sensor. If the device already has a well-defined interface, make a note of it so that you can reference it later at design time.

Three types of analysis classes in the 20151015_ system analysis phase