《UML大战需求分析》阅读笔记04

在学习了前面的几种UML图并不能满足所有情况的建模,如当流程图涉及到多种角色,并且通过对多种角色交互展开时,顺序图才是不二选择。顺序图就如同中文语法的说话语言相似,描述的是一种事件发生的顺序。顺序图分为循环及分支语法结构两种语法。它强调的先后顺序。

作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整、功能全面的系统原型。那么,这些必备的画图技巧,就会帮上很大的忙。业务用例在整个软件开发过程可以获取需求,在整个项目开发过程中起到指导其他工作流程的作用。在上机的过程中通过对自己做的系统进行业务用例描述,对这个系统的业务流程有了清楚的了解。在这个过程中就涉及到了另一种UML图:用例图。

用例图能从比较清晰启动的角度表达系统的需求,而且不涉及到技术用语。用例图和其他UML配合使用才能发挥高效。侧重于描述什么角色通过某某系统能做什么事情的图,用例图关注的是系统的外在表现,系统与人的交互,系统与其他系统的交互。首先用例图的一个小人代表着一个角色。角色是对系统使用者的抽象。一个角色可以代表着多个具体的人,既是执行者,与系统进行交互的事物。而系统应该做的事应该是以“动宾”形式描述一个用例的。多个执行者可以执行多个用例。在所有的而用例图外层都应有系统边界,系统边界内只包括用例,并没有执行者。而见他们相连的是关系。但是并不是所有用例图都需要画出系统边界,所以通常的做法是使用一个全局的用例图来宏观表达系统的需求,这样的宏观的用例图需要画出系统边界。用例图中角色的关系包括:继承、Include(包含)、Extend(扩展)。在系统开发之前,确定了用例图的同是,也确定了业务的流程。

当然,用例图不是万能的,也不是表达需求的唯一方式。学会掌握用例图所承载的需求分析方法,能够灵活的运用才是关键。

时间: 2024-10-31 11:31:52

《UML大战需求分析》阅读笔记04的相关文章

《掌握需求过程》阅读笔记04

<掌握需求过程>阅读笔记04 我们在开发我们的系统的时候要是要给用户用使用的,所以用户的使用感受非常重要,这就需要我们站在用户的角度去考虑这个系统如何让用户的使用更加的简捷,而不是站在你开发者的角度去考虑这个系统如何开发比较省我自己的事儿.抱着多一事不如少一事的态度开发出的系统是我们懒惰情况下的残次品,是注定要被淘汰的,而我们也可能因为这样的态度,面临我们的工作也将被人这样轻视.要把握好用户的使用习惯.操作环境,就需要我们去体会用户的使用感受,就需要我们具有同理心. 编写用户故事.我们可以把我

《用户故事与敏捷开发》阅读笔记04

  <用户故事与敏捷开发>阅读笔记04 今天抽出了两个小时读了<用户故事与敏捷开发>的第十二.十三.十四以及十五章并写了这篇阅读笔记.第十二章标题为"故事不是什么".IEEE 830是一本关于如何编写软件需求规格的指南,最突出的特征是使用短语"系统应该.....",但作者认为以这种方式编写系统的所有需求实际是一个不可能的任务.因为用户看到正在开发的软件时总会有有效和重要的反馈循环.他们会改变之前的想法,而且每个需求的成本是不可见的,会造成分析

UML大战需求分析——阅读笔记04

读<UML大战需求分析>有感04 开发某系统的重要前提是: 这个系统有谁在用? 这些人通过这个系统能做什么事? 一般搞清楚这件事,再画个业务流程图,就能条例清楚的表达系统的需求了.作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整.功能全面的系统原型.那么,这些必备的画图技巧,就会帮上很大的忙. 用例图是用处非常广泛,使用频率最高的UML图,它用来描述什么角色通过某某系统能做什么事情,关注的是系统的外在表现.系统与人之间的交互.

《构建之法》阅读笔记04

今天,我阅读了构建之法10-12章.总结出了自己以前一些不对的思想和做法. 以前认为对软件需求最大的人肯定就是我们的典型用户了呀.于是就可以为这些人打造一款软件就等于软件成功了.可是大多数时候我们软件已做完发现这些人根本不用我们的软件.为什么呢?因为不会用.所以我们定义典型用户的时候首要条件就是会用这款软件,然后和需求有关系的用户. 以前认为工程师做软件就是先把要做的任务分分类,然后大家把自己的任务文成,最后链接起来就可以了,可是这样做出来的软件真的解决了需求了吗?软件设计是首先要把需求先搞清楚

软件需求模式阅读笔记04

今天开始阅读<软件需求模式>的第7.8章,其中第7章主要讲的是数据实体需求模式,主要是数据处理的一些需求模式,而第8章讲的是用户功能需求模式,主要是介绍了如何应对用户的一些需求. 第7章数据实体需求模式,系统的开发者常常是以轻视,随意的态度对待信息,没有规则定义什么时候数据可以被删除,对丢失数据很松懈--而本章就是通过引入一种方案把所有的实体分为几个固定种类,增加秩序性和一致性. 活实体需求模式,它用来定义一种实体,它的信息需要保存,并且具有预期寿命.但是不能将它应用于系统配置的实体:而应该使

大道至简阅读笔记04

本周我阅读了<大道至简>的第4张——流于形式的沟通,读后反思与感慨也是颇多的,下面与大家分享一下. 为不存在的角色留下沟通的渠道,这一节对自己来说体会是最多的.之前我们或其他自己所知道的团队中都存在这样一个问题:维护旧项目比做新项目更难:或是很多时候当项目负责人员离开后,项目就中断和中止. 许多人应该深有同感.     本书中对此情况进行了说明,把这一切的原因归咎于“没有history”.历史记录(History)与注释(Comment)不是一回事.代码中的注释是为阅读代码而留备的,而Hist

构建之法阅读笔记04

2017.4.1 今天我看的是绩效管理的内容,这是一个软件在阶段性总结时所不能逃避的话题,每个团队都应该有自己的团队绩效,应该用团队绩效来评估该团队的成员在这一阶段对这个软件做出的贡献.这好像的确是一个问题.我们应该从不同的方面来评估一个人在这一阶段对软件做出的贡献.单单从一个方面去评估一个人的价值是不合理的. 每个人在每个方面的贡献都是不可低估的.另外这章中还提到了团队合作的几个阶段,开始大家聚集在一起,是团队的萌芽阶段,每个人都很生疏,不知道做事的流程,不知道在团队中该怎么做.接着团队进入磨

构建执法阅读笔记04

第九章 项目经理 项目经理的作用 协调团队成员的工作内容,把握产品定位和方向,解决用户痛点,调节团队中的矛盾,总控团队的进度,使一个团队加强交流.在一个团队中,项目经理是必不可少的一个重要角色.一个合格的项目经理需要良好的沟通能力,通过和团队成员的沟通交流,使一个团队能够有效地运转.同时,项目经理还需要及时的了解用户需求,精确地把握软件的定位与方向.而且还需要有长远的眼光和独特的见解,是产品的功能更加完善 第十章 典型用户和场景 在做一个产品之前,我们应该明确产品所需要服务的用户,为不同的用户建

编写有效用例_阅读笔记04

第十一章作为本书的第一部分的最后一个章节,提供了几种可供选择的用例格式.第一种是完整正式的用例格式,首先是单列文字,其次没有条件语句,最后便是扩展的部分的编号规则是数字和字母的组合.我个人在看了本书之后,比较喜欢这种格式,其原因一是从前看到后看习惯了,另一个原因就是扩展部分的编号规则更能让我接受. 在看了几个格式后,不禁好奇,怎么会有这么多种的模板来参照,如此不严谨的确不像是我们这类工程类的文档的要求,往后看才知道,原来影响用例书写格式的因素很多,从社会文化到理解层次到项目人员的相关要求到经验到