标签：9.png 设计模型 专注 社会 识别 兼容性 展现 inux 数据库
好了，你现在会了面向对象的各种语法了， 但是你会发现很多同学都是学会了面向对象的语法，却依然写不出面向对象的程序，原因是什么呢？原因就是因为你还没掌握一门面向对象设计利器， 此刻有经验的人可能会想到瀑布模型、螺旋模型、迭代开发、敏捷、RUP等一堆软件工程相关的软件开发流程，但对于大部分人来说这些流程仅仅只是项目管理上的流程.
本节我们就来了解下，作为一名程序员基于面向对象开发程序的开发流程：
需求模型->领域模型->设计模型->实现模型
需求：客户想要的效果，对客户有价值的事情
功能：系统为了实现客户的价值而提供的能力/功能
举例：
汽车：驾驶是需求，刹车、加速、转弯是功能
打印机：打印是需求，进纸、设定、与电脑连接等是功能
pos机：买单是需求，商品扫描、金额汇总、收银等是功能
1/3的项目失败或陷入困境是因为需求原因导致的 garbage in，garbage out 垃圾上了生产饼干的流水线，最后产出的是像拉吉一样的饼干
修复需求错误的问题成本极高
1 编码阶段修复发现一个错误耗费人类是1个单位 2 测试阶段修复需求错误的成本是5-10倍 3 维护阶段（产品上线后），修复需求错误成本是20倍 ps：在需求阶段修复错误，成本只需要0.1-0.2即可 结论：需求错了，几乎要把软件项目重做一遍
1 记录员，记录客户的需求 2 分析员，和客户一起分析，完善需求 3 引导员，能够引导客户的需求
需求分析518方法，简称我要发，具体就是5w1h8c
when:用户想在什么时间用，例如半夜备份的任务，很明显我们得知该需求需要自动化执行 where：用户想在什么地方用，例如垃圾桶室内和室外的区别，同样的事物放到不同地方用肯定不一样 who：用户想让谁来用，不仅是人，也可以是一个系统 what：用户想要我们程序的输出结果是什么，如图片，文档，系统 why：问一问用户为什么要这么做，（你不问，他基本不说），包括客户所有觉得不爽的事情 ps：why是核心
1h：how
8c：8个constraint约束
性能performance
性能是系统提供相应服务的效率。主要包括响应时间、吞吐量
性能是很多系统架构设计的关键约束条件之一
例如，同样一个web网站，虽然都是提供信息给用户流量，设计一个日访问量1w的网站与
日访问量10亿的网站，二者的设计截然不同
成本cost
成本指为了实现系统而需要付出的代价
成本也是很多系统架构设计的关键约束之一
例如客户只愿意花100w，而我们却设计了一个耗费1000w的系统
时间time
指客户要求什么时候交付
可靠性reliability
指系统长时间正确运行的能力，银行、证券、电信这些公司，对宕机时间要求很严格
安全security
指对信息安全的保护能力，涉及到钱、身份证、社会保险号等需求对这个要求很高
合规性compliance
指满足各种行业标准、法律法规、规范等，例如3C、SOX、3GPP，ITUT
技术性technology
有的客户可能要求我们采用某种技术
例如客户现在都是windows服务器，要求我们基于windows平台开发
兼容性compatibility
指我们的产品与客户其他已有的产品或系统的兼容能力，要知道现在很少有产品是孤立运行的，
特别是在大企业、大公司中，多个系统都是相互交互、互相配合的。新的系统必须能够和已有
的系统配合，否则将无法运行
5.1 写用例的技巧
三段法：NEA 1 正常处理（normal):分析正常流程 2 异常处理(exception)：分析每一步异常情况和对应的处理 3 替代处理(alternative)：分析每一步是否有其他替代方法，以及如何做
5.2用例的书写格式
#1. 用例名称 一般情况下，用例名称即需求名称 #2. 场景 场景即用例发生的环境，正好对应5w中的：when，where，who #3. 用例描述 描述详细的用例内容，对应5w中的what和how 即用户应该怎样做，以及每个步骤中的输出，但不要求每个步骤都有一定的输出，可以有也可以没有，也可以有多个 #4. 用例价值 描述用例对应的客户价值，对应5w中的why #5. 约束和限制 即真个需求流程中相关的约束和限制条件，对应518方法中的8C
5.3 用例编写案例
#用例名
答题系统
#场景：
when：8.10开始
where：西安
who：linux学院，网络客户
#用例描述：
linux学院提供50道题
每个客户无需输入任何个人信息就可以参与答题，随机选择20道题，给客户回答，每道题5分，
3.答题结束后，输入手机号，提交，算总分
60分参与抽奖，<60分赠送基础视频
#用户价值：
答题有奖，答题提交时输入自己的手机号获取成绩，获得潜在客户的联系方式，为后期将客户转成学员做准备
#约束：
暂无
需求分析阶段不区分面向对象还是面向过程
领域模型是完成从需求分析到面向对象设计的一座桥梁
领域模型定义：
领域模型是对领域内的概念或现实世界中对象的可视化表示， 又称为观念模型，领域对象模型，分析对象模型 它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系
领域模型主要两个作用：
1 发掘重要的业务领域概念 2 建立业务领域概念之间的关系
归纳领域建模的方法:
1 从用例中找名词（找完后需要删除不是领域对象的名词，具体删除什么， 与不同领域有关，没有统一标准，靠经验） 2 加属性（有些属性并没有在用例中明确给出，靠行业经验自己添加） 3 连关系（画UML图）
面向对象类设计的具体步骤
第一步：领域类映射（不是全盘拷贝）
类筛选：并不是每个领域类都会出现在软件中
名称映射：对应
属性映射：对应，照搬
提炼方法：领域类中并没有方法，在用例中找动词
第二步：应用设计原则和设计模式
第三步：拆分辅助类（领域类可以在实现阶段拆分为几个类）
选取一种支持面向对象的语言实现我们的设计，比如c++,java,python
#用例名
答题系统
#场景：
when：8.10开始
where：西安
who：linux学院，网络客户
#用例描述：
linux学院提供50道题
每个客户无需输入任何个人信息就可以参与答题，随机选择20道题，给客户回答，每道题5分，
3.答题结束后，输入手机号，提交，算总分
60分参与抽奖，<60分赠送基础视频
#用户价值：
答题有奖，答题提交时输入自己的手机号获取成绩，获得潜在客户的联系方式，为后期将客户转成学员做准备
#约束：
暂无
2.1 找名词：
找名词： linux学院，题，客户，得分，奖，视频 #筛选：去掉与领域无关的名词。视频应该算作一种奖品 linux学院，题，客户，得分，奖
2.2 加属性：
#加属性 加属性 名词 属性 备注 linux学院 NA 对于答题系统来说，并不需要linux学院的属性，因此在领域模型中，linux学院是没有属性的 题 题目编号，题目类型，题目描述，答题选项，正确答案，分数 客户 客户编号，姓名，性别，年龄，手机号 答题记录 记录编号，客户编号，题目编号列表，总分数，时间 通过答题记录就可以知道用户是谁，以及用户答过的题目 奖品 奖品编号，奖品名字
2.3 连关系：
#连关系：画图
1：答题记录是客户与题的关系类，而客户与奖品之间可以建一个关系类，这样以后单查关系类就可以知道谁得了什么奖品
2：找动词：
创建题目
随机选择题目
答题
提交
算总分
抽奖
2.4 出图
链接: https://pan.baidu.com/s/1jHYFKWI 密码: wimc
在UML系统开发中有三个主要的模型：
UML图功能模型
从用户的角度展示系统的功能，包括用例图。
UML图对象模型
采用对象、属性、操作、关联等概念展示系统的结构和基础，包括类图、对象图、包图。
UML图动态模型
展现系统的内部行为。 包括序列图、活动图、状态图。
综述
UML是数据库设计过程中，在E-R图（实体-联系图）的设计后的进一步建模。
要了解一下UML设计中有的图例及基本作用。首先对UML中的各个图的功用做一个简单介绍：
用例图
描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用
该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，
并且显示了这些元素之间的各种关系，如泛化、关联和依赖。
类图
类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写
代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型
类型。类图表示类、接口和它们之间的协作关系。
对象图
与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。
它描述的不是类之间的关系，而是对象之间的关系。
包图
包图用于描述系统的分层结构，由包或类组成，表示包与包之间的关系。
活动图
描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。
能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何
共同满足前面使用用例图建模的商务需求。
状态图
描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、
子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息
的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。
一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类
的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对
象的状态。状态图是对类图的补充。
序列图（顺序图）
序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，
即强调消息是如何在对象之间被发送和接收的。
协作图
和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建
模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；
如果强调上下级关系，则选择协作图；这两种图合称为交互图。
构件图（组件图）
描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间
的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件是软件单个组成部分，
它可以是一个文件，产品、可执行文件和脚本等。
部署图（配置图）
是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使
用者是开发人员、系统集成人员和测试人员。部署图用于表示一组物理结点的集合及结点间的
相互关系，从而建立了系统物理层面的模型。
一：这十种模型图各有侧重
1:用例图侧重描述用户需求，
2:类图侧重描述系统具体实现；
二：描述的方面都不相同
1:类图描述的是系统的结构，
2:序列图描述的是系统的行为；
三：抽象的层次也不同
1：构件图描述系统的模块结构，抽象层次较高，
2：类图是描述具体模块的结构，抽象层次一般，
3：对象图描述了具体的模块实现，抽象层次较低。
在有的文献书籍中，将这九种模型图分为三大类：
结构分类、动态行为和模型管理：
1：结构分类包括用例图、类图、对象图、构件图和部署图，
2：动态行为包括状态图、活动图、顺序图和协作图，
3：模型管理则包含类图。
类图中通过加号(+)来表示 public 通过减号(-)表示 private 通过井号(#)表示 protected
详细请看：http://www.cnblogs.com/wj-1314/p/8707772.html
标签：9.png 设计模型 专注 社会 识别 兼容性 展现 inux 数据库
原文地址：https://www.cnblogs.com/wj-1314/p/9023788.html
