原创力文档- 1、本文档共21页，可阅读全部内容。
- 2、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。
- 3、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
- 5、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
- 6、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
面向对象与UML
Object-OrientedandUML
UML图
用例分析分析类
用例分析分析类
分析类
•在系统分析阶段将分析类分成三种类型：实体类、边界类、控制类.
•UML中类有三种主要的版型：边界类《boundary》、控制类
《control》和实体类《entity》。
分析类引入边界类、控
制类及实体类的
概念有助于分析
和设计人员确定
系统中的类。
分析类图
MVC
1边界类《entity》
•边界类用于描述外部参与者与系统之间的交互。
•识别边界类可以帮助开发人员识别出用户对界面的需求。
•边界类位于系统与外界的交界处，窗体、对话框、报表、以及表示通
讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等
都是边界类。
•边界类可以通过用例确定，因为参与者必须通过边界类参与用例。
•通过用例图可以确定需要的边界类，每个actor/usercase对至少要有一
个边界类。但并非每个actor/usercase对都要生成唯一的边界类。例如:
多个actor启动一个用例时，可以用一个边界类与系统通信。
边界类的分类
一个系统可能会有多种边界类：
（1）用户界面类-帮助与系统用户进行通信的类，通过标准的I/O设备提
供人机界面。
•参与者与用例之间应当建立边界类：用例可以提供给参与者完成功能
的操作只能通过边界类暴露出来。
•例如，参与者通过一组网页、一组Windows窗口、或者字符终端或鼠
标来使用用例功能。都可以称为用例的边界类。
（2）系统接口类-帮助与其他系统进行通信的类，系统接口对象隐藏如
何与外部接口通信的细节。
•与外部系统通信的边界类负责管理与外部系统的对话，它为正在构
建的系统提供与该外部系统的接口。
•例如：在ATM系统中，提款必须通过ATM网络得到验证，然后该网
络再通过银行会计系统对提款进行验证。我们可以确定一个ATM网
络接口，让其对象来提供与ATM网络之间的通信。
（3）设备接口类-为用来监测外部事件的（硬件）设备（如传感器、Timer）
提供接口的类。
★从架构角度上来说，边界类主要位于展现层（用户界面层）。
书店系统用例图
•“售书界面”用来描述售书员与
书店系统的交互处理。
•“信用卡支付界面”用来描述信
用卡系统与书店系统的交互处理。
2实体类《entity》
•实体类是用于对必须存储的信息和相关行为建模的类。
•实体类是持久的，是永久保存的信息（需要保存到数据库或文件中）。
•通常，每个实体类在数据库中有相应的表，实体类中的属性对应数据库
中表的字段。但这并不意味着，实体类和数据库中的表是一一对应的。
有可能是一个实体类对应多个表，也可能是多个实体类对应一个表。
（与数据库设计模式有关）。
•例如：银行系统中实体类的典型示例是账户和客户。
•实体对象可以出现在多个用例中。
•实体类可以通过事件流和交互图发现。
•有时Actor也可作为实体类。
实体类
书店系统用例图
•“图书”、”书款账单”等就可以作为实体类。
思考:
还可以将什么类设计成
实体类？
★从
文档评论（0）