发现和定义对象类应以问题域和系统责任为出发点，正确地运用抽象原则，尽可能全面地发现对象的因素，并对其进行检查和整理，最终得到系统的对象类。我们可以在用例模型的基础上，通过识别实体类、边界类和控制类，从而发现和定义系统中的对象类。
　　在这里，实体类表示系统存储和管理的永久信息，边界类表示角色与系统之间的交互，控制类表示由系统支持和用户执行的任务，我们使用UML中的构造型<<entity>>、<<boundary>>和<<control>>分别表示实体类、边界类和控制类。

识别实体类
　　实体类代表系统中需要存储和关系的信息，通常是永久存在的。启发分析员发现实体类的因素包括：
　　＊ 人员：通常系统会涉及到各种各样的人员，我们需要考虑的是由系统保存和管理其信息的人员，如教师、学生等。
　　＊ 组织：在系统中发挥一定作用的组织机构，如系、班级等。
　　＊ 物品：需要由系统管理的物品，可以是有形或无形的，如课程等。
　　＊ 设备：在系统中动态地运行、由系统进行监控或供系统使用的各种设备、仪表、机器、运输工具等。
　　＊ 事件：需要由系统长期记忆的事件，如学生注册课程的记录等。
　　＊ 表格：这里的"表格"是广义的，可以是各种业务报表、统计表、申请表、身份证、商品订单、帐目、学生成绩单等，注意不要将原始的表格进行简单对应，应该是分析和整理后形成的映射一些现实事物的表格。
　　在学生课程注册系统的例子中，通过分析和理解问题域，我们找出以下实体类：

识别边界类
　　边界类代表系统与角色的接口，在每一个用例中，一个角色对应一个边界类。边界类收集来自角色的信息，并将其转换成实体类和控制类可以使用的中间接口。
　　根据角色的不同类型，边界类可以是用户接口、系统接口和设备接口。对于用户接口来说，边界类集中描述了用户与系统的交互信息，而不是描述用户接口的显示形式，如按钮、菜单等；对于系统接口和设备接口来说，边界类集中描述所定义的通信或交换协议，而不是说明协议如何实现的。
　　在学生课程注册系统的例子中，通过发现用例-角色对，我们定义以下边界类：

识别控制类
　　控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物，它负责接收边界类的信息，并将其分发给实体类。
　　控制类与用例存在着密切的关系，它在用例开始执行时创建，在用例结束时取消。一般来说，一个用例对应一个控制类。当用例比较复杂时，特别是产生分支事件流的情况下，也可以有多个控制类。在有些情况下，用例的行为十分简单，这时可以没有控制类，学生注册课程系统中的用"登录"就是这种情况。
　　在学生课程注册系统的例子中，我们发现以下控制类：