02《UML大战需求分析》阅读笔记之二

UML虽然是一种新的工具,但同时也代表了一种新的先进的思考方法,所以学习UML的关键不在于学习语法,而是要改变思维习惯。所以我觉得我还需要系统地培养几方面的能力,如书面表达能力,归纳总结能力,“面向对象”的思维能力和抽象能力。

我们现在也正在学习需求分析这门课,需求分析是我们做软件的第一步,可见其重要性。客户基本不懂计算机,但是我们却需要了解到客户的真正的需求,这是难点所在。而UML通过建模活动可以帮助我们更好地认识客户的业务和做好业务流程再造的工作。要想UML在需求分析中真正发挥作用,我还需要了解更多UML图的使用,活用UML进行结构建模和行为建模。

类图,我们都比较熟悉,也是用得最多的一种UML图。虽然我们画图的时候,觉得类图很简单,但是实际上要做到活用类图还需要很久的时间。说通俗的话,类图是帮助我们理清人、物品、事情并理清关系的用途。我们在需求分析中用到的各种业务概念、人物,抽象之后可以看作类。而构建类图,我们首先要找到类,类的属性,然后找出类之间的关系。即类图的类名、属性、操作三部分。虽然类图的基本语法很简单,但是识别类,表示类之间的关系就没那么简单了,也是我们使用类图的关键。类之间的关系主要有三大部分,直线关系、包含关系、继承关系。直线关系中我们通过一对一关系、一对多关系等分辨;包含关系中通过强烈程度来分辨;比如,如果部门没有了,员工也可以继续存在,所以是弱包含,反而如果员工也没有了,则是强包含。继承关系中有泛化关系和依赖关系,比如由A导出B,我们可称为泛化,A需要B协助来完成,但是依赖程度不一定就是依赖关系;我认为这也是类图中很重要的一部分。虽然学习了很多类和类之间的关系,但是我在这本书中真正认识到的两种类之间的关系其实是递归关系和三角关系。比如,对于文件夹和文件的关系,文件里面可以有文件夹,文件夹里面也可以有文件,是一种无穷无尽的递归状态,但是将包含关系指向文件夹本身时,这个问题就得到了完美解决。三角关系,比如公司、雇员和劳动合同,这里教给了我们一个画图的解决方法就是如果觉得两个类之间有关系的话,先画直线,如果觉得有关系却不会画,那我们可以首先找到他们的关联类,构成三角关系。要做真正的系统,我们可能要使用上百个上千个类图,所以一定要规划好类图。

我们可以通过画类图来训练我们的面向对象分析的逻辑思维,思想。我想用好类图,让它在需求分析中发挥作用,只是练习次数的问题。

时间: 2024-12-21 22:30:08

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

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

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

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

读<UML大战需求分析>有感03 状态机图和活动图在样子比较相似,但状态机图是用来为对象的状态及造成状态改变的事件建模.我们大二学习UML统一建模语言状态机图模块时了解到,UML的状态机图主要用于建立对象类或对象的动态行为模型,描述系统中某一个对象所经历的各个状态.引起状态或活动转移的事件,以及因状态或活动转移而伴随的动作.但在以前的学习过程中,我们并没有学到过"伪状态",后经查阅知:伪状态是指在一个状态机中具有状态的形式,同时具有特殊行为的顶点.它是一个瞬时状态,用于构造

UML大战需求分析--阅读笔记3

这次阅读的是第四章,流程分析利器之 – 活动图.对需求有两种分析的方式:结构建模与行为建模.活动图是行为建模中经常使用的一种图.由流程图发展而来. 活动图中有一些名词:开始状态.结束状态.活动.判断.监护.合并.泳道/分区.分叉.汇合.对象.对象流.控制流.连接件.动作等.开始状态与结束状态表示一个活动的开始和结束,开始状态用实心圆圈表示,结束状态用空心圆圈加上圆心点组合表示.活动和动作都是用圆角矩形表示,并且活动和动作都表示流程中的一个步骤,但是,活动表示的步骤可大可小,而动作表示的步骤不可分

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

我阅读了一个例子,一个软件公司采用.NET技术体系研发了一套电力系统,该系统使用的是SQL SERVER数据库.但安装系统时,客户发现该系统使用的数据库是SQL SERVER时,要求必须使用Oracle,如此一来,软件公司只能修改系统,这样的软件改动工作量是很大的.所以一定会需要软件技术框架,如果忽视了在软件技术框架.软件架构上的要求的话,会给软件后期工作带来想不到的麻烦.很多项目往往在初期就会对技术框架有一定的限制,常见的情况有:1.新项目需要在原系统的基础上开发:2.新项目需要与某些存在的系

02《火球——UML大战需求分析》阅读笔记之二

02<火球----UML大战需求分析>阅读笔记 在上一次的阅读笔记中,:我阅读的是开始部分和第一章,总结了其实UML不仅对于软件设计有很大的用处,对于软件的需求的分析也处于很高的地位.现在,读了第二章,真正的明白了UML对于需求分析的真正用处. 其实客户与我们所处的关系和医生与病人之间的关系,认识永远存在着偏差,就像对于用户和软件公司,对于需求的分析永远的存在着偏差.因为对于客户而言,每天的需求总是多变的,并且词不达意--à分析员的错误理解--à程序员的错误编码----à返回客户,客户的不满意

读书笔记---《火球:UML大战需求分析》

书评 作为一本UML和需求分析的入门书来说还算可以,写的比较接地气,如果是做过很多项目的读者,很容易找到共鸣点. 美中不足:部分概念可能有错误,其中对于Component和Artifact的解释明显和Wikipedia的解释不一样,感觉应该是错误. 结论:三星推荐. 需求分析 需求分析的难点 屁股决定脑袋,眼界决定境界,各人有各人的想法 词不达意,想到说不清楚,说清楚写不清楚,写清楚理解不清楚 需求的持续演进,一天一个样 自学业务,争取尽快超越客户对需求的理解 认真考虑,认清客户真正的需求是什么

阅读笔记 火球UML大战需求分析4

在我们整个团队的需求分析过程中,是否要单枪匹马的尽心作战,还是要一项目团队为集体来进行作战呢?在本章要学习的就是需求分析的团队作战的方式 所以,要想了解团队作战的方式,必须要知道项目团队如何集体的获取需求 1.首先,让项目组的成自己活得一手的需求,要比得到的二手的需求肯定要好的多,所以,项目组的成员一定要积极地去进行需求的获取,不能依靠队伍内提供给自己的数据来进行分析,因为每个人的思路不一样,获取的需求的方向也有可能有略微的区别 2.写需求和读需求还是有很大的区别的,所以一定要自己去写需求,加深

火球-UML大战需求分析(体验版3.0.2).pdf

http://files.cnblogs.com/files/happlyonline/%E7%81%AB%E7%90%83-UML%E5%A4%A7%E6%88%98%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%EF%BC%88%E4%BD%93%E9%AA%8C%E7%89%883.0.2%EF%BC%89.pdf

2016年秋季-《UML大战需求分析》-阅读笔记2

<火球--UML大战需求分析>的第二章的语言很有趣,而且在开始介绍的地方有一个我们非常熟悉的一个关于"软件需求与分析"的案例,在从上大学的第一门课"信息科学技术导论"上,王老师给我们看过一张非常有趣的组图,讲的就是:客户需要的是一把梯子,系统分析员了解到的是一张凳子,开发人员做出来的是一张桌子,测试人员以为是一张椅子!需求分析是高难度和折腾人的工作,以一个示例全过程的了解需要的挑战.在通过这几天的阅读后我认为:软件需求分析存在的主要困难是由于角色的不同引