天生我才必有用，会须一饮三百杯。(UML，系统分析，设计)

lwd2k 2001-10-09 07:58:21

麻烦讨论一下在UML中使用：边界类，控制类，实体类的心得？

...全文

2473 点赞收藏 33

写回复

33 条回复

切换为时间正序

当前发帖距今超过3年，不再开放新的回复

发表回复

dearxiaobao 2001-10-16

不知这与mvc有什么相似之处？

回复赞

Againstwind 2001-10-15

真是一个睡觉的好地方！！！
可以看到折磨多评论，真是不错！！！

回复赞

oocoolie 2001-10-13

我把边界类理解为每个form(当然还有与其它的外界对象有交流的，但我的程序只有form)

把实体类理解为数据库的表

控制类是中间的协调对象

？

回复赞

redswordsite 2001-10-12

Control classes provide coordinating behavior in the system. The system can perform some use cases without control classes (just using entity and boundary classes) - particularly use cases that involve only the simple manipulation of 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 classes include transaction managers, resource coordinators and error handlers.
Control classes effectively de-couple boundary and entity objects from one another, making the system more tolerant of changes in the system boundary. They also de-couple the use-case specific behavior from the entity objects, making them more reusable across use cases and systems.
Control classes provide behavior that:
Is surroundings-independent (does not change when the surroundings change).
Defines control logic (order between events) and transactions within a use case. Changes little if the internal structure or behavior of the entity classes changes.
Uses or sets the contents of several entity classes, and therefore needs to coordinate the behavior of these entity classes.
Is not performed in the same way every time it is activated (flow of events features several states).

回复赞

redswordsite 2001-10-12

Entity objects represent the key concepts of the system being developed. Entity classes provide another point of view from which to understand the system because they show the logical data structure, which can help you understand what the system is supposed to offer its users.
A frequent source of inspiration for entity classes are the Glossary (developed during requirements) and a business-domain model (developed during business modeling, if business modeling has been performed).
Sometimes there is a need to model information about an actor within the system. This is not the same as modeling the actor (actors are external, by definition). Thus, a naming convention should be employed for naming the system classes that hold actor information (e.g., class StudentActor for the actor and Student for the entity class, or Student for the actor and StudentInfo, for the entity class).

回复赞

redswordsite 2001-10-12

A boundary class intermediates the interface to something outside the system. Boundary class insulate the system from changes in the surroundings (changes in interfaces to other systems, changes in user requirements, etc.), keeping these changes from affecting the rest of the system.
A system may have several types of boundary classes:
User interface classes - classes which intermediate communication with human users of the system.
System interface classes - classes which intermediate communication with other systems.
Device interface classes - classes which provide the interface to devices which detect external events.
Boundary classes may be used as “holding places” for GUI classes. The objective is not to do GUI design in analysis, but to isolate all environment-dependent behavior. The expansion, refinement and replacement of these boundary classes with actual user interface classes (probably derived from purchased UI libraries) is a very important activity of Class Design, and will be discussed in the Class Design module.

回复赞