建模基础
这篇还是很多的概念东西 从程序员夸到设计 分析 还是有距离的 不过随着多看 多理解 对面向对象 还是慢慢有一些更多的理解！
书上写里很多原理 现在的水平也是看的云里雾里
建模
个人理解 ：建模 是确定里抽象角度 然后通过 人 事 物 规则 去表达
抽象的角度不同 建立的模 也不一样
比如 说出 筷子 勺子 盘子 的共同特征 和不同特征 都是餐具 都带‘子’字 或者都可以在商场厨房用品买到 从抽象角度不同 理解的东西也不一样
如果是餐具 我们会马上从脑海里形成 用餐的场景
如果是厨房用品 我们会马上想到 在 商场买东西的场景
我们的图 也会随着角度不一样 而改变
我们在项目里 怎么确定抽象角度 就是参与者的目标 就是你的抽象角度
一个书店网上购买系统 参与人会有 信息管理店员 和购买书籍顾客
从不同的参与人员 去建立 他们对系统的使用方式
用例驱动
用例就是参与者想做什么并得到什么
整个软件的生产过程就是用例驱动
用例驱动就是抽象角度
从用户的角度来看 不想了解系统架构 或者内部实现 他所关心的是体统提供什么服务 也就是开发出来怎么使用
我们把所有的抽象角度都考虑出来 一些问题就可能迎刃而解
我们站在学生角度 和在注册员的角度上使用的用例是不一样的
抽象层次
抽象层次是面向对象比较重要的技巧
抽象层次越高 具体信息越少 概括能力越强 反正具体信息也就越丰富 结果越确定 概括能力越弱
比如 石头 大理石 钻石 岩石 都叫石头 在具体一些就是 每一种类型的石头 硬度和形成条件都一样
抽象层次也是最难找的
抽象有俩种方法 一种自顶而下 一种从下往上
例如 介绍汽车工作原理 从发动机 转动装置 等较高层次讲 就容易理解 如果降低一个等级 从发动机原理讲起 就有人会听不懂 在降一级 从热学 和动力学 那有一些人更听不懂了
从下往上 适用于在实践中提高和改进 如果发动机出现问题 从而改进发动机结构 或者采用新的发动机原理 最终来提高汽车质量
在软件开发过程中 应当从上往下 用少量概念覆盖系统需求 在逐步降低抽象层次 一直到写代码
同时从下往上来提高软件的质量
什么阶段分析什么抽象层次 书作者要在后面开始讲 ~。。。
视图
UML视图 有好几种
每一种视图有不同的意义 这个是自己找的 估计会在后面看到 在做详解
视角
不同的干系人有不同的视角
建模的重要工作就是 给不同的干系人展示他们所关系的视角
在一个公司管理软件上 把HR部门的东西 工作流程 展示给开发看 肯定是一个很灾难的事情
或者 我们在了解一个整体公司业务流程的时候 问了一个小部门的业务员 那么肯定需求确定下来也是不对的 以后肯定面临着各种风险
所以客户提供的信息有的时候出现问题 或者缺失的时候 我们应该反思 是不是向正确的客户询问里正确的问题 并且给他们看里正确的内容
我们在实际工作的时候 也也要经常思考
应该为哪些软件信息绘制哪些视图
应该给哪些干系人展示哪些视角
对象分析方法
一切都是对象：一切有名字的都系都是对象 都应该使用对象的观点来看待
对象都是独立的：对象与对象是独立的 只有在某个场景下他们才会互相联系在一起 所以我们分析对象 也需要分析很多个该对象实例参与的场景 已获得对象的多个侧面 在归纳整理多个实例抽出的对象一般特性 这就是兑现分析的方法 也是UML建模采取的方法 参与分析的对象越多 信息就越准确
对象都有原子性 对象原子性是抽象层次有意义的重要保证 一旦破坏 就显得混乱
对象虽然要有原子性 但是也要有边界 如果对象是一个鸡蛋 蛋壳就是边界 如果非要打破边界 我们是理解内部结构里 发现手上也沾满里蛋清 糟糕的设计会一片混乱
我们在分析一个商业模式的时候 哪怕规模再大 如果银行 商场 我们也理解成一个对象 不能把银行分成工商和建行
我们应当分析过程中所有对象的认识附加在对象边界上 在实现这个对象之前不理会其内部细节 这叫面向接口编程
对象都是可抽象的 在分析过程中 应该关注那些参与多个场景的对象 它们往往是分析设计中的重点
对象都有层次性 对象层次越高 其描述的越粗略 但是适用广 ；层次越低则描述越清晰 适应力越下降
每写一章都特别的累 但是收获还是很多 今天的努力一定会化成明天的钞票 ！UML 设计模式 框架 的学习 加油了！！！！