01.模型的概念、UML概述

软件系统分析与设计的学习笔记

模型的定义

模型是对实体的特征及变化规律的一种表示或抽象，即把对象实体通过适当的过滤，用适当的表现规则描绘出的简洁的模仿品。

模型是实体的认知。例如：通过研究地产市场获得房价预测模型
通过模型可以掌握实体的特征行为变化规律。例如：股票预测模型
通过模型解决现实问题。例如：天气预测模型
建模的意义与误区
一个真实的系统可能比较庞大，也可能含有许多细节，常常超过人类智力可能认知的范围，所以人们必须从系统中抽离出重要的现象，让人们能够认识与理解系统的重要特性，包括系统各组件的静态与动态合作关系。
误区一：建模就等于写文档、画图
误区二：建模是在浪费时间（尤其是对于小系统）
建模的过程可以分为三步

UML概述

目标

了解UML中的视图
了解UML中的图
了解掌握软件开发模型（RAD）

概念

UML（Unified Modeling Language）统一建模语言是一种建模语言，用来为面向对象开发系统的产品进行说明、可视化和编制文档的方法，UML与开发语言无关。
UML描述了一个系统的静态结构（系统的组成部分，类、对象、组件）和动态行为（对象之间如何交互，交互的顺序）。静态结构定义了系统中的重要对象的属性和操作，以及这些对象之间的相互关系。
UML由视图（View）、图（Diagram）、模型元素（Model Element）、通用机制（General Mechanism）等组成
具体如下图所示：

UML中的视图

一个系统可以从不同的角度进行描述。从其中某一个角度观察到的系统称之为一个视图（view）。
UML中的视图包括：用例视图、逻辑视图、组件视图、并发视图和配置视图。
一个视图中可以由多个图组成。
用例视图：它从外部角色的视角来展示系统的功能，用例视图是系统中与实现无关的视图。用例视图不包含实现。
逻辑视图：用来描述如何实现用例视图中提出的系统功能。它提供系统的详细图形，描述组件间如何关联。逻辑视图既描述系统的静态结构，也描述系统内部的动态协作关系，它通过系统的静态结构和动态行为来展示系统内部的功能是如何实现的，其侧重点在于如何实现功能。
并发视图：主要考虑资源的有效利用、代码的并行执行，以及系统环境中异步事件的处理。除了将系统划分为并发执行的控制以外，并发视图还需要处理线程之间的通信和同步。
组件视图：组件是不同类型的代码模块，包含模型代码库、执行文件、运行库和其他组件的信息组件视图描述系统的实现模块，以及它们之间的依赖关系。
配置视图：显示系统的物理部署，主要关注系统的实际部署，处理容错、网络带宽、故障恢复与响应时间，可与系统的逻辑结构有所不同。配置视图利用节点来展示系统部署的物理架构

UML中的图（9种）

新版2.0里面包含14种，不用太纠结

学习目标

理解各类视图的概念以及使用场合
掌握各类视图的组成元素
掌握各类视图的制作方法
理解掌握面向对象分析设计方法

简要介绍

用例图：描述了系统提供的一个功能单元。包括基于基本流程的“角色”（actors，也就是与系统交互的其他实体）关系，以及系统内用例之间的关系。

类图：类图显示了一组类、接口和协作，以及它们之间的关系，显示了系统的静态结构。类图在面向对象的建模设计中是很常用的。

对象图：对象图展现了一组对象，以及它们之间的关系。对象图是类图的变体，它使用与类图相似的符号描述，不同之处在于对象图显示的是类的多个对象实例而非实际的类。例如：班级类对象（计科1912班）对应多个学生类对象（张三、李四、王五）

状态图：表示某个类所处的不同状态和该类的状态转换信息。一般说来，状态图是对类所描述事物的补充说明，它显示了类的所有对象可能具有的状态，以及引起状态变化的事件。例如：学生类：入学前，入学后，毕业后都是不同状态，每个状态可以进行不同的操作。

活动图：活动状态代表了一个活动，即一个工作流步骤或一个操作的执行。活动图由多个动作状态组成，当一个动作完成后，动作状态将会改变，转换为一个新的状态。（也可理解为业务流程图）

时序图显示多个对象间的动作协作，重点是显示对象之间发送的消息的时间顺序。一个时序图显示了一系列的对像和在这些对象之间发送和接收的消息。从代码角度来看，就是方法或函数的调用。

协作图：协作图显示了一系列的对象和这些对象之间的联系，以及对象间发送和接收的消息。
时序图主要侧重于对象间消息传递在时间上的先后关系，而协作图表达对象间的交互过程及对象间的关联关系。后者注重关联无时间先后。

组件图：组件图显示了一些组件和它们之间的关系。使用组件图可以说明系统的静态实现。组件图和类图是有联系的，通常一个组件可以映射成一个或多个类、接口或协作。例如：web项目里面通常有DAO组件。

配置图：用于显示系统中的硬件和物理结构。配置图显示了一些节点和它们之间的关系，表示该软件系统如何部署到硬件环境中使用配置图可以说明系统的静态结构。

UML应用领域

UML是一个通用的统一建模语言。适用于系统开发模型中从需求规格描述到系统完成后测试的不同阶段。
需求阶段：用例图
设计阶段：类图、顺序图、协作图、状态图、组件图

用例图：用户模型视图

用例模型描述的就是外部参与者所理解的系统功能。画好用例图是由软件需求到最终实现的第一步。
用例图元素包含：

Actor

活动者（Actor）：活动者是系统外部的一个实体（何以是任何事物或人），它以某种方式参与了用例的执行过程。

识别参与者：
谁将使用该系统的主要功能？
谁将需要该系统的支持以完成其工作？
谁将需要维护、管理该系统，以及保持该系统处于工作状态？与系统交互的是什么系统？
谁或什么系统对本系统产生的结果感兴趣？

Use case

用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。
识别用例：
特定参与者希望系统提供什么功能？
系统是否存储和检索信息？如果是，这个行为由哪个参与者触发？
当系统改变状态时，通知参与者吗？
存在影响系统的外部事件吗？
是哪个参与者通知系统这些事件？

关系

用例之间的关系：用例除了与其参与者发生关联（Association）外，还可以参与系统中的多个关系这些关系包括：泛化（Generalization）关系、包含（Include）关系和扩展（Extend）关系。
关联关系：表示参与者用例之间进行通信，连接执行者和用例，表示该执行者所代表的系统外部实体与该用例所描述的系统需求有关。（实线箭头表示）例如：售票员与售票用例是关联关系。

泛化关系：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改改变已继承的行为。例如：购票用例可以泛化为支付宝订票、网络订票、APP订票等。（空心箭头，和类中泛化一样）

包含关系：虽然每个用例的实例是独立的，但是一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这称做包含关系。在UML中，包含关系表示为虚线箭头加$\text{<<include>>}$字样，箭头指向被包含的用例。例如：售票与打印车票是包含关系，这里需要注意售票员执行售票用例，会连带执行打印车票用例，谁去售票大厅买票不拿车票呢。打印车票这个用例对于手机购票的用户是可选项。

扩展关系：扩展关系和包含有点类似，但是不是强制执行的关系，例如网上订票用例与打印车票用例就是扩展关系，网上订票可以不打车票，直接身份证上车。这里需要注意扩展是从扩展用例（打印车票）指向被扩展用例（网上订票）的。虚线箭头加$\text{<<extend>>}$字样

在Powerdesigner里面除了包含和扩展，还有很多其他关系（比Rose的要多），但都统一叫依赖关系（Dependency）

实例：图书管理系统的用例图

画出图书管理员与下面五个用例的用例图：
书籍借阅
书籍归还
超期罚款
预订信息管理
用户状态检查