The training effect is good, because at the time, some problems have not been sorted out in the brain, so I can't ask for any problems on the spot. I will organize the problem as follows:
1. Analyze the software requirements, use the software with the user's perspective, find the Scenario that happens, abstains into a USE case, analyzing the relationship between USE CASE, this step is very important, this step is done, design It is half a half. So how do Scenario abstracted into use case, is it more confused, what is the principle of this?
2.
Border class definition:
* Intermediate the interface to something outside the system
* Several Type
- User Interface Classes
- System Interface Classes
- Device Interface Classes
* One Boundary Class Per actor / use case pair (each pair of actor / use case has a border class)
Control class definition:
* Use-case behavior coordinator
* One Control Class Per Use Case (there is a control class for each use)
Analyze the event stream of use case, find verbs, analyze the control logic of the physical class, so you can design a business control class, which can generally be a control class, or you can logically related entity classes by a Facade session bean. (Non-eJB meanings) to unify control, the granularity of the control class in this is mastered by himself.
My doubts are in the hierarchical structure of Dao <-sevice <- Control (Action), which level should be located, what kind of dependency is in?
It is expected that this deeper training is regarded, and how to decompose a USE CASE, and how to make a revelation in the next design.
P.s:
Association: It is some method and attributes of the instance of the A object with the instance of the B object, but the instance of the B object will not be destroyed by the destruction of the instance of the A object.
(Such as hand and keyboard relationship)
Combination: A object of an object is an instance of the B object. Generation is generated, and it is destroyed because of an instance of the B object. A is part of B
(Such as hand and people's relationship)
Aggregation: A object of an object is that the B object is generated during the calling process, and it is destroyed because the B object is destroyed.
(Such as the relationship between the sound and mouth)
