大象Thinking in UML读书笔记一

      一直以来想找一本书来帮助我学习UML这一先进工具(不知道这样说对不到),苦于不得法,书看不少,但不得要令,有的书看得没发看下去。这几天有幸看到《大象Thinking in uml》这本书。初看一下,两个字:好书!

第一部分  准备篇--需要了解

     1、为什么需要UML

      面向对象方法(我个人很喜欢作者对面向对象的描述),是将世界看作一个个相互独立的对象,相互之间并无因果关系,只有在某个外部力量的驱动下,对象之间才会依据某种规律相互传递信息。从微观角度说,这些独立的对象有着一系列奇妙的的特性。例如,对象有着坚硬的外壳,从外部看来除了它用来与外界交互的消息通道之外,对象内部就是一个黑匣子,什么也看不到,这被称为封装;再例如对象可以结合在一起形成新的对象,结合后的对象具有前两者特性的总和,这称为聚合;对象可以繁育,产下的孩子将拥有父辈全部的本领,这称为继承;对象都是多面派,它会根据不同的要求展现其中的一个面,这就是接口;多个对象可能长着相同的脸,而这张脸背后却有着不同的行为,这就是多态。从宏观角度说,对象是“短视”的,它不知道它身处的整个世界是怎么回事,也不知道它的行为是如何贡献给这个世界的。它只知道与它有着联系的身边的一小群伙伴(这称为依赖),并与伙伴间保持着信息交流的关系(这称为耦合)。同时对象也是“自私”的,即便在伙伴之间,每个对象也仍然顽固地保持着自己的领地,只允许其它人通过它打开的小小窗口(这称为方法)进行交流,从不会向对方敞开心扉。

        

         抽象层次,好处是不论在哪一个层次上,我们都只需要面对有限的复杂度和有限的对象结构,从面可以专心地了解这个层次上的对象是如何工作的;抽象层次的另一个更重要的好处是低层次的零件更换不会影响高层次的功能。

  

               面向对象的困难(说真的,这也是我想搞明白的东西,因为如此所以没学成,当然,不排除智商因素)

  • 对象是怎么被抽象出来的?现实世界和对象世界看上去差别是那么大,为什么要这么抽象而不是那么抽象呢?(Why)
  • 对象世界由于其灵活性,可以任意组合,可是我们怎么知道某个组合就正好满足了现实世界的需求呢?什么样的组合是好的,什么样的组合是差的呢?(How)
  • 抛开现实世界,对象世界是如此的难以理解。如果只给我一个对象组合,我怎么才能理解它表达了怎么样的含义呢?(What)

     抽象是面向对象的精髓所在,同是也是面向对象的困难所在。我们需要:

  • 一种把现实世界映射到对象世界的方法。
  • 一种从对象世界描述现实世界的方法。
  • 一种验证对象世界行为是否正确反映了现实世界的方法。

image

建立模型是指通过客观事物建立一种抽象的方法,用来表片事物并获得对事物本身的理解,再把这种理解概念化,并将这些逻辑概念组织起来,形成对所观察的对象的内部结构和工作原理的便于理解的表达。

 

抽象过程:从现实世界到业务模型,从业务模型到概念模型,从概念模型到设计模型

 

绘制分析模型最主要的无模型有:

  • 边界类(boundary)。边界是面向对角分析的一个非常重要的观点。狭义上说,边界就是大家的界面,所有对计算机的操作都要通过界面进行。从广义地说,任何一件事物都分为里面和外面,外面的事物和里面的事物之间的任何交互都需要有一个边界。换句话说,边界决定了外面能对里面做什么“事”。
  • 实体类(entity)。原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物,UML采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息,建立逻辑关联,添加那些实际业务中不会使用到,但是执行计算机逻辑时需要的控制信息等。
  • 控制类(control)。边界和实例都是静态的,本身并不会动作。UML采用控制类来表述需求中的动态信息,即业务或用例场景中的步骤和活动。从UML的观点看来,边界类和实体类之间,边界类和边界类之间,实体类和实体类之间不够直接相互访问,它们需要通过控制类来代理访问要求。

image

image

image

RUP(Rational Unified Process)译为统一过程。是一个采用了面向对象思想,使用UML作为软件分析设计语言,并且结合了项目管理、质量保证等许多软件工程知识给综合而成的一个非常完整和庞大的软件方法。它归纳和集成了软件开发活动中的最佳实践,它定义了软件开发过程中最重要的阶段和工作(四个阶段和九个核心工作流),定义了参与软件开发过程的各种角色和他们的职责,还定义了软件生产过程中产生的工件(见注),并提供了模板。最后,采用演进式软件生命周期(迭代)将工作、角色和成果物串在一起,形成了统一过程。

image

只有掌握了软件过程,才会知道为什么要有用例,为什么要有分析模型;站在软件过程的立场,那些孤独的UML视图才会变得有生命力,才会知道在什么时候,在什么地方需要用什么样的UML图符来表达软件的观点,也才会知道UML的那些视图到底在软件开发过程里起到他什么作用。

image

统一过程学习的困难在于庞大和复杂,而UML学习的困难在于不知如何使用。

 

 

2   建模基础

建模(Modeling),是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解,同时把这种理解概念化,将这些逻辑组织起来,构成一种对所观察的对象的内部结构和工作原理的便于理解的表达

第一个问题“怎么建”,依赖于方法论,再上升一点到哲学高度就是认识论。

做需求的时候,首要目标不是要弄清楚业务是如何一步一步完成的,而是要弄清楚有多少业务的参与者?每个参与者的目标是什么?参与者的目标就是你的抽象角度。与分析一个复杂的业务流程相比,单独分析参与者的一个个目的要简单得多。实际上,这就是用例!这也就是为什么用例会成为业务建模的方法的原因之一。

第二个问题“模是什么”,则依赖于确定了抽象角度下的场影模拟。

image

 

2.2用例驱动

  • 逻辑视图
  • 进程视图
  • 部署视图
  • 实施视图

2.3抽象层次

在软件开发过程中,主体上应当彩自顶向下的方法,用少量的概念覆盖系统需求,再逐步降低抽象层次,直到代码编写。同时应当辅以自底向上的方法,通过总结在较低抽象层次的实践经验来改进较高层次的概念以提升软件质量。

2.4视图

需要搞明白的两个问题

  • 应该为哪能些软件信息绘制哪些视图?
  • 应该给哪能些干系人展示哪些视角?

2.5对象分析方法

  • 一切都是对象
  • 对象都是独立的
  • 对象都具有原子性
  • 对象都是可抽象的
  • 对象都有层次性

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值