软件工程之面向对象分析与设计

文章链接:https://codemouse.online/archives/2020-05-15124035

面向对象的基本概念

对象：一组属性以及这组属性上专用操作封装体。
消息：对象间通信手段，通过发送消息请求服务。
继承：基于层次关系不同类共享数据和操作机制。
分类：一组具有相同属性和相同操作的对象集合。
多态：不同对象对同一个操作产生不一样的结果。
动态绑定：不是编译之前就把对象和类绑定在一起，编译的时候对象和类才会产生一定的联系。

面向对象的分析与设计过程

面向对象分析步骤

获取客户的系统需求
以需求选择类和对象
定义类的结构和层次
建造对象—关系模型
建造对象—行为模型
用用况/场景来复审分析模型

面向对象设计步骤

系统设计
对象设计
消息设计
复审

系统设计

将分析模型划分成子系统
标识问题本身的并发性，并为子系统分配处理器
任务管理设计
数据管理设计
资源管理设计
人机界面设计
子系统间的通信

UML概述

UML发展

1994年开始研究统一的方法
1996年UML0.9
1995年Jacobson加盟
1997年UML1.0
2004年UML2.0

模型元素

视图与图

内部结构图：内部结构图展示了类的分解，给出了组成一个结构化类元的相互连接的部分、端口和连接器。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YB3EiVKU-1592880955681)(https://store.codemouse.online/pic/a191628e50b2299ef7197f218276d311.png)]
协作图：协作图展示了协作的定义，是一种合成的结构图。协作是为了完成某一目的而一起工作的一组对象间的上下文关系。

用况建模

概念：用况建模是用于描述一个系统应该做什么的建模技术。用用况图来描述。
作用：用况图展示了各类外部执行者与系统所提供的用况之间的连接。
联系：一个用况是系统所提供的一个功能的描述，执行者与用况的连接表示该执行者使用了那个用况。

用况建模步骤

定义系统：获取用户的需求，明确系统的组织型态。
确定执行者：确定系统有哪些种类的用户。
确定用况：系统有哪些功能。
描述用况：描述系统里功能是怎么样的，怎么去运作的。
定义用况间的关系：功能与功能之间的联系。
确认模型：对整个模型的确认。

用况图

确定执行者

执行者：指与系统交互的人或其它系统，代表一种角色，而不是具体的某个人。
主执行者：使用系统的主要功能。
副执行者：处理系统的辅助功能。
主动执行者：开始一个用况。
被动执行者：从不开始用况，只是参与一个或多个用况。

确定用况

用况的特征
- 用况总是被执行者启动的，执行者必须直接或间接地指示系统去执行用况
- 用况向执行者提供的值必须可识别
- 用况是完整的，一个用况必须是一个完整的描述
- 用况是一个类，而不是实例，用况的实例称为场景
用况的描述：通常用正文来描述或活动图来描述。
- 用况的目的
- 用况是如何启动的
- 执行者和用况之间的消息流
- 用况中可供选择的流
- 如何通过给执行者一个值来结束用况
用况的详细描述
- 前置条件和后置条件：表示用况开始和结束的条件
- 事件流(flow of events)：事件流是一系列陈述句，它是从执行者的角度，列出用况各个步骤用况描述中可以包含条件、分支和循环。

描述用况

用况名称：订购货物
参与的执行者：客户、客户代表
前置条件：一个合法的客户已经登录到这个系统
事件流：

当客户选择订购货物时，用况开始
客户输入他的姓名和地址
当客户输入产品代码
a. 系统给出产品描述和价格
b. 系统往客户订单中添加该物品的价格
循环结束
客户输入信用卡支付信息
客户选择提交
系统检验输入的信息，保存订单，向记账系统转发支付信息
支付确认后，订单已确认，返回给客户一个订单ID，用况结束
后置条件：如果订单没有被取消，它将保存在系统中，并做上标记
其他需求

如果在订购货物用况中，客户可以在提交订单前随时取消订单，其可选路径如下：

在选择提交前的任何时候，客户都可以选择cancel。这次订购没有被保存，用况结束。
在基本路径第6步，如果有任何不正确的信息，系统提示客户去修改这些信息。
在基本路径第7步，如果支付没有被确认，系统将提示客户改正支付信息或者取消。

事件流

基本路径：是运转正常时的路径，是没有分支和选择的简单陈述句。
可选路径：不同于基本路径而允许不同的事件序列的路径。

用况关系

描述用况

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9vMd2u3c-1592880955691)(https://store.codemouse.online/pic/a6d6962ce4edbb15767972781beefec6.png)]

用况实例

  一个简化的银行储蓄账户管理系统，该系统可在银行的柜台上对客户办理活期储蓄业务。
系统的需求陈述如下：客户可以通过银行职员进行开户、存款、取款、转账、注销账户等活动。其中转账分为银行内转账和银行间转账。系统管理员负责系统的账户管理及业务报表的生成。

识别执行者
客户
银行职员（客户代理）：银行工作人员，代表客户进行储蓄业务的操作
银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户
管理员：银行计算机的管理人员，负责账户的管理和业务报表的生成
确定用况
描述用况

开户用况
用况名称：开户
参与的执行者：银行职员（客户代理），客户
前置条件：一个合法的银行职员（客户代理）已登录到该系统
事件流：
1.当选择开户功能时用况开始
2.输入客户信息（姓名、地址、身份证号等）
3.从账户管理系统获取新的账号
4.请客户输入密码
5.请客户再次输入密码
6.如果两次密码不一致则回到第4步，否则继续
7.在账户库中添加新账户
8.打印存折，用况结束
后置条件：在账户库中增加了一个新账户，得到一张新存折
取款用况
用况名称：取款
参与的执行者：银行职员（客户代理），客户
前置条件：一个合法的银行职员（客户代理）已登录到该系统
事件流：
1.当选择取款功能时用况开始。
2.当输入客户信息(姓名、账号等)后
a)如果客户信息与账户不一致，显示错误信息，可以重新输入或结束用况。
b)如果该账户被冻结(如因挂失而冻结)，显示冻结信息并结束用况。
3.输入并校验密码。
4.输入取款金额，如果该账户的余款小于取款金额，显示错误信息，要求重新输入。
5.打印取款单，交客户签字。
6.建立取款事件记录，更新账户信息。
7.打印存折，用况结束。
可选路径:
1.在第5步客户签字之前的任何时刻，客户可以取消本次取款，用况结束。
2.第3步校验密码时，如发现密码不一致，则重新输入密码，或用况结束。
后置条件:如果取款成功，客户账户中的余额被更新(减少)，否则余额不变。

静态建模

建模构图组件

关联

二元关联：二元关联表示为在两个类之间用一条直线连接，直线上可写上关联名。
多元关联：三个或三个以上的类之间可以互相关联。
受限关联：用于一对多或多对多的关联。限定符用来区分关联“多”端的对象集合，它指明了在关联“多”端的某个特殊对象。
聚集和组合
聚集表示整体一部分关系的一种关联，它的“部分”对象可以是任意“整体”对象的一部分。

组合关联具有强的物主身份，即“整体”对象拥有“部分”对象，“部分”对象生存在“整体”对象中。
关联类：UML中可以把关联定义成类，该关联的每个链都是这个类的实例
导航性（navigability）
符号说明

泛化

实现

实现关系将一个模型元素（如类）连接到另一个模型元素（如接口），后者（如接口）是行为的规约，而不是结构，前者（如类）必须至少支持（通过继承或直接声明）后者的所有操作。可以认为前者是后者的实现。

依赖

依赖指出两个或多个模型元素之间语义上的关系。它表示被依赖元素的变化会要求或指示依赖元素的改变。

约束

派生

动态建模

状态机图组件

状态迁移

引起状态迁移的原因通常有两种：

当标在迁移箭头上的事件出现时会引起状态迁移
当状态机图中相应的迁移上未指明事件时，表示当位于迁移箭头源头的状态中的内部动作全部执行完后，该状态迁移被自动触发。

状态机图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-p4mwnA8L-1592880955716)(https://store.codemouse.online/pic/77247aefabcfca2228c50b23620ae965.jpg)]

正交状态

正交状态：多个状态并发进行的状态。

复杂迁移

复杂迁移：多个状态都满足的情况下才触发。

活动图

活动图用来描述完成一个操作所需要的活动，或者是一个用况实例的活动。
与状态机图不同的是，活动图中动作状态之间的迁移不是靠事件触发的，当动作状态中的活动完成时迁移就被触发。
活动图可以描述用况

用活动图画出取款的操作：

物理体系结构建模

系统的体系结构用来描述系统各部分的结构、接口以及它们用于通信的机制。
物理体系结构涉及系统的详细描述，它显示了硬件的结构，并展示了对进程、程序、构件等软件在运行时的物理分配。

构件图

部署图