uml和模式01
1 UML
模型语言(Modeling Language 检查ML)是一种设计语言，人们藉由设计语言来创造产品。 模型语言是人们用来设计系统模型(Model)的语言，其设计品是系统的模型，也就是产品的 蓝图。
其实最早提出模式语言的是在建筑界，建筑师Christopher Alexander在20世纪70年代就已 提出模式语言的概念，模式语言含有建筑师和居住人共同的表达方式，因此建筑师和居住人 之间能相互了解和沟通，也能让居住者了解建筑师的创意。举个例子，音乐家设计的乐谱， 也是一种模型。
软件系统方面的模型语言UML，用于软件设计师创造软件系统的蓝图，在创造过程中设计师 将他的心意、情感和经验融入模型中，程序员藉由UML和设计师沟通、心灵交汇，体会和理 解模型表达出来的内容，然后用擅长的程序语言表达成为真实的软件，同时由于各个程序员 理解和水平关系，根据同一个uml蓝图设计编写的软件质量会有很大的差别。
UML应用于软件需求分析时，其学习门槛将会大大降低!语法复杂度会降低，用户不需要掌握 软件开发的知识，只要清楚产品需求，认真学习和应用UML，就可以和设计师通过UML在需求 分析阶段达成共识。
我们在用乐谱作为例子，音乐家使用音乐模型语言(乐谱)，表达他的心意、情感和经验，演 奏者通过音乐模型语言(乐谱)和音乐家沟通、心灵交汇，体会和理解模型表达出来的内容， 然后用擅长的乐器演奏出音乐。同时由于各个演奏者理解和水平关系，根据同一个乐谱演奏 偶的音乐水平会有很大的差别。
UML有很多种图，大体可以分为两类，涉及到需求分析的是用例图，类图是最常用的UML图， 后面我们会重点描述。
结构型的图(Structure Diagram) 类图(Class Diagram) 对象图(Object Diagram) 构件图(Component Diagram) 部署图(Deployment Diagram) 包图(Package Diagram) 行为型的图(Behavior Diagram) 活动图(Activity Diagram) 状态机图(State Machine Diagram) 顺序图(Sequence Diagram) 通信图(Communication Diagram) 用例图(Use Case Diagram) 时序图(Timing Diagram)
2 用例图
用例图(Use Case Diagram)表达了系统提供给用户那些服务，这些是用户看得见的或感觉得 到的，而且是用户觉得有意义的、需要的功能，这些是系统需求的核心部分，所以是UML想 要表达的重点所在。
简而言之，用例在系统的众多功能当中，属于直接提供用户服务的部分，例如水利云系统， 它具有"新建项目"、"项目缓存"、"项目编辑"、"文件转换"、"要素输出"、"数据读取"、" 文件上传"、"权限控制"、"地图显示"等等，其中只有一小部分是用户能看到、感觉到的， 又觉得有意义的服务，就是用例，而系统的其他功能就不称为用例。就如黑客帝国第二集里 先知所说："你看看那些鸟，有程序在控制它们，还有风、树、日出、日落何有程序在负责它 们，着些程序你看不到，但是却起关键作用。"，这些程序占了系统的大部分，但是都不是 用例，它们属于质量需求，对支持用例起了关键作用。
但是系统最终的目的是用例，给用户提供有价值的服务，所以UML用例图就特别凸显系统受 益面的功能，所以期待在系统创建就能确保系统切中用户的需求；就如盖房子，在初期就要 和用户明确房子的规格、面积、外观、结构细节，如果房子改到一般，在做修改，这时房子 已将固化，很难再做改动了，只有推到重改；软件也是一样，在初期非常灵活，开发开始后， 就会逐渐固化，修改成本加大，所以在初期用例分析非常重要。
UML用例图用于表达用户观点下的系统功能需求，着重于系统的行为需求，描述系统如何 (How)服务用户，包括系统与用户交互及对话的流程，确保用户体验。
Use Case描述能更清楚的表达出系统的行为需求，每个用例皆表达了系统行为的需求的一部 分，在用例图中表示了用例的外观行为，在用例描述里应详细描述用户使用系统的流程，例 如[注册用户]用例描述：
UC:注册用户
用户行为 系统响应
------------ ------------
1. 输入登陆名 1.1 判断合法性，只能使用数字、字母，长度大于2小于16
1.2 如果登陆名已注册，给出提示
2. 输入用户名 判断合法性，长度大于2小于16
3. 输入密码 判断合法性，不能使用中文，长度大于6小于20
4. 输入手机号 判断合法性，不能使用数字，必须以13或15开头，长度11位
5. 发送验证码 5.1 如果手机号空，不可发送验证码
5.2 如果手机号已注册，给出提示
6. 注册 6.1 如果有合法性错误，不可点击注册
6.2 如果没有勾选《青清水利网站服务协议》，不可点击注册
6.3 如果验证码输入错误，给出提示
6.4 如果验证码超时，给出提示
3 用例和类的关系
你必须仔细分辨用例(Use Case)、对象(Object)与系统(System)的不同，以及它们的相关性， 用例是描述系统的服务项，用例是系统的一个观点(View)，是用户(User)内心对系统的期待， 所以UML用例图表达了用户心中期待系统给予的服务，也就是用户对系统的需求，输入系统 外观，在用户眼中，系统就像是青蛙眼中的池塘，用例就是青蛙眼中的荷叶，青蛙眼中的各 片荷叶之间没有相连，也不关心各个荷叶在水下是如何连接在一起的，至于架构师和设计师 则要关心水面下的根茎如何支撑水面的荷叶，水面下的许多子系统或对象，用于支持水面的 各片荷叶，不同的用例可要求同一个对象提供服务，一个用例可要求多个对象提供服务，用 例和对象之间是多对对关系。
类是面向对象的思维，人们心中都有对象概念，并且系统就是一群具有智慧、善于传递信息 的对象组成的，用户心中的对象，是架构师心中的对象，亦是程序员心中的对象，容易达成 心心相印的境界，赋予对象人性，是面向对象的重要步骤，社会是由一群有智慧、能沟通且 互助合作的个人组成，软件则由一群有智慧、善于传递信息的对象组成，这就是对象的人格 化。每个对象都有自己的职责，就是对象的方法了，面向对象关键是划分合适的对象，给每 个对象分配合适的职责，然后由这些活生生的对象互助合作完成任务。
4 类图
这里简单介绍一下关系，类有继承、实现、依赖、关联、聚合、组合几种关系，简单介绍一 下：
[继承]指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能，类似于人类的父
亲和儿子的关系
[依赖]可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、
非常弱的，但是B类的变化会影响到A，比如某人要过河，需要借用一条船，此时人与船之间的关系
就是依赖
[关联]体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比
依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一
般是平等的、关联可以是单向、双向的
[聚合]是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之
间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象
共享；比如计算机与CPU、公司与员工的关系等
[组合]也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；
他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分
的生命周期结束；比如你和你的大脑
说到类关系，就要说说设计模式了，软件是人类心灵和智慧在虚拟空间的投射，软件的性能 就是人类能力的扩展，它的活动就是人类心智活动的反映，然而，人类的软件却是问题多多， 面对变化的需求，软件往往过于僵硬，过于脆弱，不易复用，难以维护，而软件设计中出现 的问题，其实就是人类自身技术、能力、心智的不足，提高软件能力的办法，其中最重要的 就方法就是设计模式，就是类与类之间特定的关系组合，用于解决特定问题。
举个例子：策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的 类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生 变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略 类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。
一个围棋下的好的人知道，好的"形"对围棋非常重要，形是棋子在棋盘上的几何形状的抽象 化，形就是模式，也是人脑把握和认识外界的关键，软件比起围棋更加复杂，所以形(模式) 更加重要。我们都知道风水，强调的是建筑和环境的相互作用，认为建筑物与其环境是一个 和谐的整体，这个整体会给居住在其中的人带来特定的体验，对于一个软件设计师来说，模 式就是软件的风水，所以研究设计模式非常重要，研究类关系非常重要。
