《UML大象》第二阶段阅读总结

在第二阶段中我对基础篇和进阶篇进行了阅读。

基础篇对UML的基础概念重新组织和归纳整理,进行扩展和讨论,引申出针对UML的这些概念在面向对象方法中应用方法的思考。进阶篇以一个实例贯穿全篇,阐述如何使用UML从头到尾地实施一个项目。

首先,要从现实世界到业务模型。现实世界,无论是哪个行业,无论做什么业务,其本质无非是由人、事、物和规则组成的。人是一切的中心,人要做事,做事就会使用一些物并产生一些物,同时做事需要遵循一定的规则。人驱动系统,事体现过程,物记录结果,规则是控制。而UML中的用例恰好可以表达人事物规则,“参与者”代表人,“用例”代表事,“业务场景”和“用例场景”通过UML视图体现了规则,而 “业务对象模型”就代表了中间用到的物。这样现实世界就映射到业务对象模型。通过这一步,一种把现实世界映射到对象世界的方法就找到了。

其次,要从业务对象模型到概念模型。上一步说的业务对象模型,还只是用UML描述现实世界,和真正的计算机软件还差的太远。当业务模型用分析类来描述的时候,实际上我们已经采用了对象的视角。用例所代表的现实的业务过程,被“边界”、“控制”、“实体”以及“包”、“组件”等概念替代。而这些概念是可以被计算机理解的,是抽象化了的对象,现实世界千差万别的业务,都用这几个固定的元素来表述,也就是现实世界已经被抽象成了几个固定的概念。可以说,从业务模型到概念模型正是我们需要的一种从对象世界来描述现实世界的方法。

最后,从概念模型到设计模型,“边界”、“控制、“实体”这些对象虽然是计算机可以理解的,但是并不是真正的对象实例,不是可执行代码。应该将其转换Java,C#,C++代码才能执行。其中,“边界”类可以映射到对应的“界面”,“控制”可以映射为“控制类”,“实体”可以映射为对应的“实体类”,这样,从概念模型就映射到了设计模型。

经过上边的三个步骤,运用面向对象的分析设计方法就将现实世界通过推导,最终转换成了一个可以运行的软件系统。而且可以从类得设计到概念模型,再到对象模型,一步步验证最初的现实世界。软件系统不再是拍脑袋想出来的,也不是拷贝以前的项目改来改去改出来的,而是通过一定的方法一步步推到出来的。

在进阶篇中那个例子很好的启发了我,作为学习软工的菜鸟,见识到一个真正的项目是如何的开发出来的真心不容易,同时我在网上也搜到了许多前辈写的读后感,他们都是工作了好几年的人,介绍了他们在职场之内是如何开发项目的,对我挺有用的。

时间: 2024-08-02 02:48:14

《UML大象》第二阶段阅读总结的相关文章

《UML大象》第一阶段阅读总结

全书分为准备篇.基础篇.进阶篇和总结篇四个部分.我的阅读计划分为三个阶段,所以我把最后两个部分列为了一个阶段,在第一阶段我阅读了准备篇. 准备篇讲述面向对象分析的一些基本概念,及学习建模需要了解的一些基本知识. 这些知识在我们之前的学习中都有涉及到,我简单整理了一下. 面向对象是基于一种哲学思想,它认为:客观实体和实体之间的联系构成了现实世界的所有问题,而每一个实体都可以抽象为对象.这种思想尽可能地按照人类认识世界的方法和思维方式来分析和解决问题,使人们分析.设计一个系统的方法尽可能接近认识一个

《UML大象》第三去阶段阅读总结

在看到本书的总结的时候我才发现总结篇就是对于现实中很多的问题进行的分析,我觉得看书还不如看前辈们的一些工作经验来的实在,所以我搜集了很多从事IT人员的工作经验,了解了他们在刚进入工作然后慢慢一步步如何成功在这个领域站住自己位置的. 对于进入职场的人来说几年的工作经验,也做过一些项目,大小公司也见过几个.对于项目型公司来说,先是销售去谈项目,然后项目经理去做需求,然后回来做项目,一般情况,项目经理首先回来大概分几个模块,每个模块大概做些什么,设计一些类,一些流程,然后程序员开始编码,中途如果有任何

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

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

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

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

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

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

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

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

《梦断代码》第二阶段阅读感想(包括第3、4、5共三章)

第三章  原型与Python 在这一章中,我又更加深刻的认识到做软件的难,它就像洋葱一样层层叠叠,每一层都辛辛苦苦地建立在前一层的基础之上,危如累卵.无论如何,日积月累,一层一层搭建 起来,即“抽象层叠”,而抽象层的最低端就是汇编语言,是最让我学习起来头疼的汇编语言,也是大多数人难以学习和编写的,后来产生了许多适用性更强的高级语言,也就随之 出现了编译. 后来发明了Python,虽然这一脚本语言不像其他高级语言得到人们的那么重视,但是Python凭借自己的优点发挥了比其他预言更多的智能特性,比如

UML 结构图之类图 总结

[注] 本文不是类图的基础教程, 只是类图的图形总结. 学习UML图形 推荐阅读<UML参考手册>第2版. http://www.umlchina.com/ 推荐微软的开发软件设计模型 http://msdn.microsoft.com/zh-cn/library/dd409436.aspx 类图展示了面向对象系统的构造模块.描绘模型(或部分模型)的静态视图,显示它包含的属性和行为,而不是详细描述操作的功能或完善方法. 类图最常用来表达多个类和接口之间的关系. 〇 概述 可使用的工具集(EA工

项目管理-范围管理-项目需求规格说明书

项目在客户的眼中,需求经常是含糊不清的,他们也经常道不清述不明,客户内部也常常众口不一.客户没有责任把需求整理好来告诉你,就算告诉你的也不一定就是他们最终想要的,所以作为项目经理,“范围管理”是非常重要的活动.这里主要讲述一下我作为项目经理的职能时,在项目范围管理中,进行的收集需求.定义范围.创建WBS.确认范围.控制范围的过程. 项目管理-时间管理-甘特图(http://www.cnblogs.com/wgp13x/p/4385475.html)是我的项目管理专辑的第一篇,他们都很重要. 一.