系统分析与设计基础：统一建模语言.pptx

《系统分析与设计基础：统一建模语言.pptx》由会员分享，可在线阅读，更多相关《系统分析与设计基础：统一建模语言.pptx（49页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件项目开发工程组织管理广西柳州职业技术学院 信息工程系第五第五章章 系统分析系统分析与设计基础：统一建模语言（与设计基础：统一建模语言（UMLUML）课程教师：盘承军电子邮件：第三部分：软件项目分析与设计 课程目标掌握项目的一般概念，理解和区分软件项目与非软件项目之间的基本异同。了解现代软件项目实施要求的基本领域知识及其内容。理解项目软件过程定义的基础知识，能够定义简单项目的项目软件过程。掌握软件项目目标识别的方法，能够编写简单的项目愿景文件。理解实际项目软件过程中各主要里程碑阶段需要交付的工作产品和种类。初步掌握过程交付产品的生产技能和相应的基础知识。根据课堂提供的实训项目过程最佳实践，能

2、够组织符合自己情况的项目实践。完成本课程要求的实训项目任务内容和目标。课程内容提要课程编号内容名称5.1.统一建模语言（UML）基础知识导论5.2.类图与对象图：如何描述现实世界的静态结构5.3.用例与用例图：如何描述问题和问题解决方案的目标与价值5.4.活动图：如何描述问题解决方案中的措施与执行次序5.5.包图：如何描述问题解决方案中业务/软件功能组织静态结构5.6.序列图：描述问题解决方案中，对象之间的互动及生命周期5.7.状态机图：描述问题解决方案中，对象之间的关联实现依赖状态5.8.组件图：描述问题解决方案中，交付产品的基本逻辑结构5.9.部署图：描述问题解决方案中，最终交付产品运行的

3、环境场景5.10.其他：细化解决方案中业务/软件架构模型所需的其他规格说明5.11.如何组织基于UML的软件项目开发同样的东西（对象）在不同人的眼里同样的东西（对象）在不同人的眼里 如果在你的世界里出现了这样的事情如果在你的世界里出现了这样的事情 抽象画抽象画？还是表达某种神秘信息的作品？还是表达某种神秘信息的作品？想做什么事情？想做什么事情？5.1.5.1.统一建模统一建模语言（语言（UMLUML）基础知识导论）基础知识导论UML（Unified Modeling Language）定义说明1.是国际对象管理组织OMG制定的一个通用的、可视化建模语言标准，可以用来规格化（specify）、可

4、视化（visualize）、构造（construct）和记载（document）软件密集型项目的各种工件，一种在世界得到广泛应用的图注方法式的语言；2.为建模者提供现成可用的、富有表达力的、可视化的建模语言，以开发和交换有意义的模型；3.提供可扩展性和特殊化机制以延展核心概念；4.支持独立于编程语言和开发过程的规范；5.为理解建模语言提供正式的基础；6.推动对象工具的成长；7.支持更高级的开发概念，如构件、协作、构架和模式。5.1.1.5.1.1.业务目标：用户视角的业务目标：用户视角的UMLUML用例：定义和描述用户从系统中获取价值的各种方法，为了获得一个想要的结果，可能需要执行一系列相当复

5、杂的步骤；用户的动作不是决定因素，这些动作产生的结果的用途才是最关键的。用例图在一个高层次的图中对用户和系统之间的交互进行建模，这种图用一种很容易理解的格式来帮助客户和开发人员理解系统的意图和规模，随后这些用例可以被用来跟踪开发进度和指导开发活动；用例规约：用规定的格式文字说明用例，包括用户和系统之间的交互细节；活动图：对用户和系统在用例中的交互进行可视化描述。活动图和日常所说的流程图的主要区别：活动图描述用例相关人为了完成用例目标需要参与或者执行的活动的序列；流程图描述某个工作产品从初始化到完成其用途生命周期的需要进行加工的各个工序环节序列。5.1.2.5.1.2.设计目标设计目标（类、属性

6、和行为）：设计者视角的类、属性和行为）：设计者视角的UMLUML类图：详细地定义和约束一组对象，表明了实现这个类的对象必须有的状态、行为、以及其他对象的关系；状态图：描述一个类的状态相关的行为，特别地描述一个对象如何根据当前的内部配置情况来响应不同的请求；包图：描述系统各部分之间的依赖关系，这种关系是由系统的不同部分的对象之间的关系决定的；序列图：表明一个对象是如何与其它对象进行交互来提供某个功能，它能清楚描述这些交互的次序，但在确定对象之间的关系方面作用不大。通讯图：表明一个对象是如何与其它对象进行交互来提供某个功能，与序列图相反，协作图清楚地揭示对象之间的关系，但他在确定交互的顺序方面用处

7、不大。5.1.3.5.1.3.过程过程目标：管理者视角的目标：管理者视角的UMLUML5.1.4.5.1.4.交付目标：所有相干人视角的交付目标：所有相干人视角的UMLUML5.2.5.2.类图和对象图类图和对象图设计时候的用途类图：类图展示了面向对象系统的构造模块。描绘了模型或部分模型的静态视图，显示它包含的属性和行为，而不是详细描述操作的功能或完善方法。类图最常用来表达多个类和接口之间的关系。泛化（Generalizations），聚合（aggregations）和关联（associations）分别是类之间继承，复合或应用，及连接的表现。；对象图：对象图可以认为是类图的特殊情形，是类图元

8、素子集，被用来及时强调在某些点，类的实例间的关系。这对理解类图很有帮助。他们在构造上与类图显示没有不同，但是反映出多样性和作用。5.2.1.5.2.1.对象图及一般使用对象图及一般使用1.描述简单的业务场景，此时不需要很精确表达方法和属性5.2.1.5.2.1.对象图的一般使用对象图的一般使用2.从对象图中简单划分出一些抽象的分类5.2.2.5.2.2.类图及其使用类图及其使用1.识别并约束业务领域的类5.2.2.5.2.2.类图及其使用类图及其使用2.在迭代中优化分析类课程作业指南作业编号作业任务关联工作产品模板要求说明5.1.使用 VS 2010 的Model项目模板，构建你的项目模型内容

9、，尽可能详细地给出项目的主要的业务类图。无课堂实训，限时45分钟5.2.3.5.2.3.类关系说明类关系说明5.2.3.1.5.2.3.1.类类关系约束概说关系约束概说5.2.3.2.5.2.3.2.One-To-One Unidirection One-To-One Unidirection 关系说明关系说明 场景：张先生-车（张先生一次只开一台车）。关系：张先生：知道是哪一辆车（车子public的属性：车牌号、车型、颜色、车况）；张先生：能够使用车子提供的操作功能和接口（车子public方法：打火、踩离合、挂档）；车子：不知道谁来开它的，不知道张先生想去哪，更不知道会如何开。状态：张先生：

10、地理位置发生了变化（同时知道车子的状态）车子：汽油少了10升，轮胎磨损了一些（不会知道张先生的状态的）价值：张先生：到达目的地、知道车况良好、提高了驾驶技术车子：旧了（贬值）影响：张先生：下次再开这部车是否可以再快些，还是相反？构建：张先生：需要会开车，即拥有一个功能方法，在这个方法中实例化车子类使之成为“小汽车”，然后了解“小汽车”的属性，根据自己的愿望使用小汽车公开的方法。5.2.3.1.1.One-To-One 5.2.3.1.1.One-To-One Unidirection Unidirection 关系关系UMLUML类模型和代码类模型和代码5.2.3.3.One-To-One 5

11、.2.3.3.One-To-One Bidirection Bidirection 关系说明关系说明场景：银行卡收银台（一张银行卡一次只在一个收银台消费）。关系：银行卡：知道收银台的情况（收银台public的属性：可用的银行卡种类、位置）；银行卡：能够使用收银台提供的操作功能和接口（收银台public方法：验证密码）；收银台：知道银行卡哪一张银行卡（银行卡Public的属性：发卡行、卡号、余额）；收银台：能够使用银行卡提供的功能（银行卡public的方法：消费）。状态：银行卡：余额减少。收银台：营业额增加。价值：张先生：可用额度下降，能够承受的消费能力降低。收银台：提高了向财务部转交资金的能力

12、，可以让商店更快地进货销售。影响：银行卡：是否要提醒持卡人该添钱了？收银台：是否需要增加人手？构建：银行卡：可以实例化柜台，使用收银台为银行卡公开的密码校验方法。收银台：可以实例化银行卡，使用银行卡的消费功能的方法。5.2.3.3.1.One-To-One-BiDirection 5.2.3.3.1.One-To-One-BiDirection 关系关系UMLUML类模型和代码类模型和代码.One-To-One Bidirection One-To-One Bidirection 模型的业务实现模型的业务实现.One-To-Many UniDirection.One-To-Many UniDi

13、rection 关系说明关系说明场景：统计表登记表（一份统计表使用多份登记表来获取统计结果）。关系：统计表：知道所有的登记表的细节（登记表public的属性：姓名、性别、出生年月）；登记表：不知道统计表的任何内容（不知道要统计什么、如何统计）。状态：统计表：获得统计数据。登记表：没有什么变化。价值：统计表：人口状态分布。登记表：表明社区人员个体的存在。影响：统计表：社区服务设施配置是否合理？改进点在哪个方面？登记表：无。构建：统计表：提供一个方法（或者说接口），成批接受和处理所有的登记表。登记表：不需要为统计表提供什么东西。5.2.3.4.1.One-To-Many Unidirection

14、5.2.3.4.1.One-To-Many Unidirection 关系关系UMLUML类模型和代码类模型和代码5.2.3.5.One-To-Many 5.2.3.5.One-To-Many Bidirection Bidirection 关系说明关系说明场景：通知文件执行报告（一份通知文件要求产生多份执行报告）。关系：通知文件：知道执行报告的内容（执行报告public的属性：报告人、报告时间、进度）；执行报告：知道通知的内容（通知Public的属性：任务名称、活动安排、内容要求、时间）；状态：通知文件：完成总体的任务（关注目标）。执行报告：按质量在给定的时间安内完成通知的具体任务要求的活动

15、（关注过程）。价值：通知文件：创造了新的东西或者做了一件事情。执行报告：交付过程执行结果的工作产品。影响：通知文件：下一次发通知应该注意什么事情？执行报告：下一次接到类似的通知，如何更好地改进执行力？构建：通知文件：为执行报告提供蓝图，可以使用执行报告的接口获取任务执行状态的数据。执行报告：可以实例化通知文件，读取通知的内容。5.2.3.5.1.One-To-Many Bidirection 5.2.3.5.1.One-To-Many Bidirection 关系关系UMLUML类模型和代码类模型和代码.Many-To-One.Many-To-One Unidirection Unidirec

16、tion 关系说明关系说明场景：游客景点（多个游客可以同时参观一个景点）。关系：游客：知道景点的内容（景点public的属性：构成、形状、色彩、进度）。景点：完全不知道游客的情况，不知道谁在参观，不知道谁会对它做些什么。状态：游客：见识（以参观过的景点来度量）增加了。景点：门票收入增加。价值：游客：以景点为背景照了一张照片，可以向别人介绍景点的情况。景点：积累了货币，创造了新的货币价值。影响：游客：是否值得再来一次，或者告诉别人这个景点很不错或者很一般？景点：门票收入多了，是否扩容或者相反？构建：游客：所有游客在参观景点的方法里，可以实例化景点，对这个实例进行处理。景点：没有我什么事情，全由游

17、客说了算。5.2.3.6.1.5.2.3.6.1.Many-To-One Many-To-One Unidirection Unidirection 关系关系UMLUML类模型和代码类模型和代码5.2.3.7.5.2.3.7.Many-To-One BMany-To-One Bidirection idirection 关系说明关系说明场景：车票 检票口（多张车票通过一个检票口验票）。关系：车票：知道检票口的内容（检票口public的属性：放行车次、放行时间、地理位置）；检票口：知道车票的内容（车票public的属性：车次、路线、时间）；状态：车票：通过。检票口：通口人数增加。价值：车票：可以

18、用来登车。执行报告：交付过程执行结果的工作产品。影响：车票：查票、保险、报销？检票口：负荷能力是否满足？构建：车票：提供一个供验票口检查信息的方法，具备使用检票口验证的方法。检票口：提供一个供车票验证的方法，具备使用车票信息公开的方法。5.2.3.7.1.5.2.3.7.1.Many-To-One Many-To-One Bidirection Bidirection 关系关系UMLUML类模型和代码类模型和代码.Many-To-Many.Many-To-Many UniDirection UniDirection 关系关系说明说明场景：体育场举行的演唱会结束了，观众自由离场（任何人可从任何口

19、离开）。关系：观众：知道门口的内容（门口public的属性：方向、相邻地点）；出口：不知道观众的内容；状态：观众：完成离场的任务（关注目标）。出口：保持开放就行，不管有多少人离开。价值：观众：做了一件事情。门口：完成了作为通道的任务。影响：观众：下一次离场应该注意什么事情？门口：折旧？构建：观众：需要门口的实例来了解方向、相邻地点。门口：只关注自己的属性变化即可。5.2.3.8.Many-To-Many 5.2.3.8.Many-To-Many UniDirection UniDirection 关系关系UMLUML类模型和代码类模型和代码5.2.3.9.5.2.3.9.Many-To-Man

20、y BMany-To-Many BiDirection iDirection 关系说明关系说明场景：体育场举行的演唱会准备开始，观众凭票入场。关系：观众：知道门口的内容（门口public的属性：方向、相邻座位区）；出口：知道观众的内容（票）；状态：观众：完成入场的任务（关注目标）。出口：保持开放，如果票不对拒绝入场，或者告知观众选择更好的入口。价值：观众：进场，可以享受一场演唱会的表演。门口：验证了观众的票。影响：观众：下一次入场应该注意什么事情？门口：验票的效率、对于错票的处理措施？构建：观众：需要门口的实例来了解方向、相邻地点。门口：需要观众的实例来验证观众所持票的属性。5.2.3.9.1

21、.5.2.3.9.1.Many-To-Many Many-To-Many BiDirection BiDirection 关系关系UMLUML类模型和代码类模型和代码5.2.3.10.5.2.3.10.一个常见一个常见的类图表达的业务场景的类图表达的业务场景5.2.3.11.5.2.3.11.聚合关系说明一览表聚合关系说明一览表聚合通常被用来描述由更小的组件所构成的元素，这些元素是可以独立存在的，在整体中可以被替换。5.2.3.12.5.2.3.12.聚合类聚合类关系实现的一种途径（关系实现的一种途径（DIDI）5.2.3.13.5.2.3.13.聚合类关系实现的一种途径（聚合类关系实现的一种

22、途径（DIDI）5.2.3.14.5.2.3.14.组合聚合组合聚合关系说明一览表关系说明一览表这是聚合关系的强制实现，这些元素不可以独立存在的，在整体中一般也不可以被替换，并且完全依赖整体的存在而存在。5.2.3.15.5.2.3.15.在组合在组合聚合聚合关系中，下面的代码有什么问题？关系中，下面的代码有什么问题？这些元素不可以独立存在的使用独立的类表示元素时，其属性必须包含一个整体对象的特征，如果整体对象的特征为null，则被composite进来的这些元素（类）无法创建，或者没有意义。使用内嵌类。在整体中一般也不可以被替换一旦初始化整体对象后，只改变被composite对象的属性，但不

23、要更换对象。并且完全依赖整体的存在而存在对于持久化对象数据，一旦删除整体对象的数据，必须同时删除被composite对象的持久化数据，或者被composite对象的数据未删除，整体对象的数据不能删除。5.2.3.16.5.2.3.16.停车场管理系统基础业务类图停车场管理系统基础业务类图5.2.3.16.1 5.2.3.16.1 通过基础通过基础业务业务类实现权限管理说明类实现权限管理说明5.2.3.17.5.2.3.17.停车场停车场管理系统前台业务管理系统前台业务类类图（迭代二）图（迭代二）课程作业指南作业编号作业任务关联工作产品模板要求说明5.2.根据课堂授课内容，优化并标注你在课堂实训

24、练习的作业。无个人作业，将你完成的成果，通过电子邮件在下次课之前提交。5.3.各项目小组安排将业务类分析作为需求分析的一部分，策划相关的 Sprint Backlog。无项目负责人于下次课程之前提交。5.4.各项目小组参照本课件 5.2.3.16.重新优化项目基础设施的管理，至少在静态结构上保证系统用户管理及操作权限分配可以实现。无项目负责人于下次课程开始之前使用word，通过电子邮件提交。5.5.各项目小组开始设计实训系统的初级界面，界面场景至少包括如 5.2.3.16.1.内容，能够说明项目软件的功能实现环境。无项目负责人于下次课程开始之前使用word，通过电子邮件提交。5.6.各项目小组将项目软件界面的实现交付作为 Product backlog 的之一或者更多，策划完成这个product backlog，需要几个sprint，每个sprint中再安排哪些bakclog以及对应的工作任务？无小组讨论确定，直接实现在各自项目的工作区内，下次课程开始之前检查。课程作业提示本次学习结束，谢谢您的参与！本次学习结束，谢谢您的参与！