系统的需求分析.pptVIP

下载本文档

1
0
约1.66万字
约 106页
2023-09-17 发布于广西
举报
版权申诉

系统的需求分析.ppt

1、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。。
2、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击这里二次下载。
3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
4、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
5、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
6、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
7、VIP文档为合作方或网友上传，每下载1次，网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档

5.3 系统需求的UML静态建模（1）．标识实体类当分析设计人员进行标识实体类时，他们给对象、对象属性以及职责进行命名，并做简短描述。对象使用惟一的名字有利于建立一套标准术语。描述对象，即便是简短的描述，也可使开发人员澄清他们使用的概念，从而避免误解(例如，对两个不同但是相关的概念使用同一个对象)。然而，考虑到分析模型仍处于不断变化中，开发人员不必花太多时间来处理对象或其属性的细节。如果对象的属性和职责是显而易见的，那么开发人员应记录这些属性和职责。在其他情况下，对每个对象进行试验性的命名以及简短的描述就已经足够了。以后将会有很多次的重复，重复过程中，会对对象不断进行修改。然而，一旦上一页下一页返回 5.3 系统需求的UML静态建模分析模型稳定下来，每个对象的描述就应该尽可能的详细。在学籍管理系统中，可以按需求描述标识出的实体类有学生、班级、班主任、成绩以及登录用户实体类等。如图5-14。实际上实体类主要是由描述这些实体的信息（Information）组成如登录用户实体类就是由用户代码、用户名、密码及权限等内容组成。（2）．标识界面类(交互类) 界面类(交互类)表示系统与使用系统的参与者的接口。在每一个用例中，每个参与者至少与一个界面类(交互类)进行交互。界面类(交互类)从参与者收集信息，并将这些信息存入系统指定的结构中，该结构可以被实体类或业务逻辑类使用。上一页下一页返回 5.3 系统需求的UML静态建模界面类(交互类)对用户界面进行粗略的建模。它们并不详细描述用户界面的可见方面。例如，像“按钮”或“菜单项”这些界面类(交互类)都太详细了。首先，开发人员用草图或实体模型可以更方便地讨论用户界面的细节。其次，作为可用性测试的结果，用户界面的设计将不断演化，甚至是在系统的功能性说明稳定下来以后仍在演化。每次更新分析模型都要改变界面的可见部分是非常耗时的，而且这样做不能带来任何实质性的好处。在学籍管理系统中，登录界面类（frmLogin）、主界面类（frmUserAdd），学费报表类（DataReportTuition）等如图5-15所示，都属于界面类(交互类) 上一页下一页返回 5.3 系统需求的UML静态建模（3）．标识业务逻辑类业务逻辑类负责协调界面类(交互类)和实体类。通常，业务逻辑类在现实世界中没有具体的对应部分。在用例和业务逻辑类之间通常有着密切的关系。业务逻辑类通常在一个用例的开始被创建，当用例终止时就不再存在。它负责从界面类(交互类)收集信息并将信息发送给实体类。例如，一个学生学籍信息的查询系统里,查询结果的界面类(交互类)只负责显示查询结果，而处理查询条件和生成查询结果则由业务逻辑类来完成。同时业务逻辑类和界面类(交互类)在实际开发中可能不易明显混的区别，界面类(交互类)中有一部分是用来处理业务上一页下一页返回 5.3 系统需求的UML静态建模逻辑的。如图5-16交费类型设置类（frmTuitionSet），学费设置查询类（frmTuitionSetQry），公用模块类（Moudle1），其中公用模块类（Moudle1）是单纯的业务逻辑类，不直接与用户交互信息，而交费类型设置类（frmTuitionSet）学费设置查询类（frmTuitionSetQry）既有界面类的特点，又有业务逻辑类的特点，它既与用户交流信息，还要处理访问数据库、数据加工、结果反馈等业务逻辑。 3．对对象进行归纳建立模型通过对对象之间的关系归纳，可以消除对象设计中的冗余。如果两个或多个类共享属性或行为，则它们的相同之处被上一页下一页返回 5.3 系统需求的UML静态建模统一进一个超类。例如，一般操作人员、授权人员和管理员都能登录系统，只不过是权限不同而已，他们都通过用户名和密码来登录系统，并依赖用户名来分配其不同的功能(如图5-17所示)。为了清楚地对这种相似性建模，我们引入一个抽象的登录用户类，根据其权限标识的不同来继承这个抽象类，并在登录后实例化为一个具体的用户。（1）。确定对象之间的关联关系对象之间的数量关联关系对象之间的数量关联关系是指在UML中，一个对象关系中的两端点可能把任意一个整数集作为它的数量关联关系。一对上一页下一页返回 5.3 系统需求的UML静态建模一的对象关系在每一端点都有一个1。两个类之间是一对一关系(例如图5-18，班主任和班级)，这意味着，在每个类的实例间恰好只存在一个连接（即，一个班级只能有一个班主任，并且一个班主任只管理一个班级，这也我们的一般约定）。登录管理类与主界面类也是一对一的对象关系，一个登录管理对象只能对应一个主界面对象，而一个主界面对象的登录只能通过一个登录管理对象实现。一对多的对象关系在一个端点为1，另一端点为n(也可