首页 > 代码库 > 《UML大战需求分析》阅读随笔(三)

《UML大战需求分析》阅读随笔(三)

一:

需求中提到的各种业务概念、人物等,经过抽象后都可以视之为类。

 

平时遇到的人、物,我们将遇到的都是具体的人、物,也就如程序中的对象,是一个实实在在的东西。

当我们分析需求的时候,设计模型的时候,我们就需要将之抽象,也就是最关键的一步——提炼

提炼出这个东西,我们所需要的部分。

 

比如,在教室,主要存在两类人,学生和教师。

当我们做的项目为:人员管理系统

在如上的环境中,我们需要的是学生和教师的姓名和年龄、学号(工号)等这些利于了解基本信息的数据。那么,我们进行模型设计的时候,类图就应该主要包含这些东西。

 

当我们做的项目为:培训管理系统

我们需要的是学生的知识水平和接受能力,老师的知识水平、表达能力和讲课经验。这些才利于培训的分配和安排,那么设计的类图就应该包含这些东西

 

上面两个简单例子,就是区分在需求分析的时候,我们考虑的对象,在我们所做的项目下,我们需要从中真正需要的是什么,也是使用我们的软件的客户,真正看到的、使用到的是什么,要让其存在意义。

 

二:

类之间也存在关系

一切从直线开始,表示它们之间存在某种关联关系

 技术分享

“导航”关系,例如通过请假单可以找到请假者

 技术分享

“包含”关系,空心菱形是“弱”包含,实则为聚合,实心菱形是“强”包含,实则为组合,两者的区别主要是强烈程度不同。

 技术分享

“继承关系”,学生、讲师都“继承”了员工,它们具备员工的属性,也有自己的特有的属性。实则为 泛化

 技术分享

“依赖”关系,但依赖程度是相对而言的,不一定是A没有B就不能“生存”了,对于某个事情,A需要B来协助才能完成,这也为一种依赖。好比烟鬼和香烟

 技术分享

技术分享

 

 

 

三:

利用类图来描述一些架构,如公司的组织架构。

比如某公司由一个一个的部门组成,类图表达其组织结构可能如下:

 技术分享

但这样没有显示出类图的优势,没有发挥抽象和提炼的优势。进一步改进如下:

 技术分享

这就更加形象了,有助于我们在项目进行中,分类和分层,更加清晰地看见其内部结构,成果思路也更有层次。

《UML大战需求分析》阅读随笔(三)