东北大学——软件需求分析与系统设计——第四章笔记整理（2020年3月整理）

本文链接：https://blog.csdn.net/momentni/article/details/109257468

本文详细探讨了软件体系结构的重要性，包括体系结构优先权、模型—视图—控制器（MVC）框架、J2EE核心体系结构以及PCBMER模型。此外，还深入介绍了状态规格说明，如对象状态、类建模、关联建模等。行为规格说明部分涵盖用例建模、活动建模和交互建模。最后，阐述了状态变化规格说明中的对象状态建模及其触发因素。

摘要由CSDN通过智能技术生成

全笔记PDF版下载链接：下载链接

有用的话记得一键三连哦！！

本章目录

一、体系结构优先权（Architectural Prerogatives)
二、状态规格说明（State Specifications）
三、行为规格说明（Behavior Specification）
四、状态变化规格说明（State Change Specifications）
- （一）对象状态建模
- - 1.性质
  - 2.状态转换的触发（trigger）

一、体系结构优先权（Architectural Prerogatives)

（一）体系结构设计

1.软件体系结构

软件体系结构定义了系统中相互作用的软件构件及子系统的结构及组织形式
重点放在功能性需求上，非功能性需求暂不考虑
所有软件建模的最重要的目标就是将构件依赖最小化
目的是开发一个能用好用的软件，利于软件开发
架构设计：层次化结构
构建软件的适应性的重要必要条件——遵照某个公认的体系结构框架，优先进行体系结构设计

（二）模型—视图—控制器框架（Model—View—Controller，MVC）

1.定义及性质

MVC的3个抽象类对象
- 模型对象：表示数据对象——应用问题域中的业务实体和业务规则
  - 模型对象的变化由事件处理通报给视图对象和控制器对象
    - 事件处理：发布者给订阅者对象发送通知的过程（发布者/订阅者技术）
  - 视图对象：表示用户界面（UI）对象
  - 控制器对象：表示鼠标和键盘事件
MVC是框架、元模型、编程环境

MVC框架

（三）J2EE的核心体系结构（Java 2 Platform Enterprise Edition）

1.定义及性质

J2EE是以MVC为骨架的扩展，用以简化和规范企业应用系统的开发和部署
J2EE是分层结构，表示层、业务层和集成层包含应用程序构件，客户层和EIS层处于系统外围
- 客户层——用户通过客户层与系统交互
- EIS层——企业信息系统层，也称资源层，是任意的持久信息传递系统
- 表示层——用户通过表示层来访问应用程序
- 业务层——包含表示层中的控制器构件还没有实现的一部分应用逻辑
- 集成层——负责建立和维护与数据源的连接

J2EE核心框架

（四）表示—控制器—bean—中介者—实体—资源（PCBMER）

1.定义和性质

PCBMER体系结构遵循了体系结构设计中广泛认可的发展趋势
借用了J2EE核心框架中的外层（客户层和EIS层）
图中的层表示为UML节点，带箭头的虚线表示依赖关系
PCBMER的层次不是严格线性的，上层拥有的相邻下层可以不止一个
核心框架的两种版本
1. 用UML包来定义
2. 用UML子系统来定义

2.PCBMER的6个层次

表示层——表示屏幕以及呈现bean对象的UI对象
控制器层——表示应用逻辑
bean层——表示那些预先确定要呈现在用户界面上的数据类和值对象
- bean数据由用户输入或由==实体对象（实体层）==创建
- bean层不依赖于其他层
中介者层——建立了充当实体类和资源类媒介的通信管道
- 隔离了实体层和资源层，这样一来，二者的变化能够独立地引入
- 在控制器层和实体/资源层之间充当媒介
实体层——相应控制器和中介者，由描述“业务对象”的类组成
资源层——负责所有与外部持久数据源（数据库、Web服务等）的通信和连接

3.PCBMER的3个优点

层之间相关性的分离
去除了依赖关系的循环，得到了只存在向下依赖的6层结构
确保相当高的稳定性

4.PCBMER的7条原则

向下依赖原则（Downward Dependency Principle，DDP）——底层比高层更稳定，使通信变为单向
向上通知原则（Upward Notification Principle，UNP）——使通信变为单向
相邻通信原则（Neighbor Communication Principle，NCP）——使通信只能在相邻节点之间
显式关联原则（Explicit Association Principle，EAP）——运行时的关联都要在编译时显式出现
循环去除原则（Cycle Elimination Principle，CEP）——降低系统的复杂性
类命名原则（Class Naming Principle，CNP）——类名 = 层名首字母 + 类名
相识包原则（Acquaintance Package Principle，APP）——相关类以包的形式封装

PCBMER核心框架

二、状态规格说明（State Specifications）

（一）状态（State）

1.对象的状态

对象的状态由它的属性值和关联决定

2.状态规格说明

状态规格说明 = 数据结构模型
提供系统的静态视图
识别系统中所有类及类与类之间的关系
侧重于实体类（业务对象）的定义和关系，不考虑类的操作

类规格说明

（二）类建模——迭代增量式

1.发现类

名词短语方法（Noun Phrase）——核心方法
- 候选类
  - 相关类（Relevant）——类名的名词在需求文档中频繁出现
  - 无关类（Irrelevant）
  - 模糊类（Fuzzy）——最大的问题，需要进一步分析
- 需要假定需求文档是完整而正确的（而事实上很难做到）
公共类模式方法（Common Class Pattern）——将对象世界划分成有用的组
- 候选类
  - 概念类（如航班预定）
  - 事件类（如航班到达）
  - 组织类（如旅行社）
  - 人员类（如乘客）
  - 地点类（如旅行社办公室）
- 为识别类提供了有用的指南，但仅仅只是个指南，不能提供全面、关系紧凑的解决方案
- 可能导致类名的误解
用例驱动方法（Use Case Driven）
- 有自底向上的特点
- 与名词短语方法类似，效率更高一些
- 准确性依赖于用例模型的完整性和准确性
CRC方法（类—职责—协作）
- 通过分析对象之间为了完成处理任务而传递的消息来识别类
- 作用：一种发现类的技术
- 重点：如何在系统中均衡分布处理能力
- 适用于：验证由其他方法发现的类；确定类的属性
混合方法
- 根据领域知识来发现类的初始集合
- 公共类模式方法提供辅助的指导
- 名词短语方法和添加新类
- 用例驱动方法验证已有的类
- CRC方法对所有类进行集体讨论（头脑风暴）
发现（实体）类的指南
- 每个类的清晰的目的陈述
- 一组对象的模板描述（一般不考虑单例类）
- 每个实体类都应该有一组属性
  - 标识属性：主键（keys）
  - 标识类的对象：对象标识符（OID）
- 每个类应该有区别于其他类的属性
- 类拥有一组操作

2.对类进行说明

类的命名
- 每个类都要有一个名字，且互不重名
- 使用单数名词，每个实词首字母大写
- 在不隐晦、不冗余的前提下使名字尽可能长（<=30）
类的属性
- 属性名使用小写字母（如streetName或street_name）

（三）关联（Association）建模

1.发现关联

主要关联的发现是类发现过程的一个副产品（Side effect）
类的一些属性就是与其他类的关联
用例的“预演”（Dry-run）过程可以发现其余的关联
避免三元及以上的关联

2.说明关联

关联的命名
- 一般情况下可以省略，当两个类之间超过一个关联同时存在时，必须有关联名
- 命名规则遵循类名的约定
关联角色的命名
- 一般省略，用于解释较复杂的关联，特别是自身关联（递归关联）
- 命名规则遵循属性名的约定，并以the开头
确定关联的多重性
- 如果多重性不明确，其上下边界可以省略

（四）聚合（Aggregation）及复合（Composition）关系建模

1. 4种聚合语义

ExclusiveOwns聚合——如“书具有章节”的关系
- 存在依赖性（Existence-dependency）：一个复合对象被删除，其构件也不复存在
- 传递性（Transitivity）：C是B的一部分，B是A的一部分，则C是A的一部分
- 非对称性（Asymmetricity），A是B的一部分，但B不是A的一部分
- 固定属性（Fixed property），B1是A1的一部分，则B1决不是Ai （i≠1）的一部分
Owns聚合——如车有轮胎，轮胎依赖于车存在，也可以独立存在，但单独一个轮胎意义不大
- 存在依赖性
- 传递性
- 非对称性
Has聚合——两者之间没有存在依赖，如“学院有系，没有某个系也可以存在”的关系
- 传递性
- 非对称性
Member聚合——有成员关系就行，可以是多对多的多重性，如“会议有主持人”的关系

2.发现聚合和复合的方法

在说明这种关系时使用短语“具有”（has）和“是…的组成部分”（is part of）
复合是聚合的一种特殊情况

3.说明聚合和复合的方法

实心菱形 ◆：复合
空心菱形 ◇：聚合

（五）泛化（Generalization）关系建模

1.泛化的2个目的

可替换性（Substitutability）——子类对象可以替换父类变量
(2)多态性（Polymorphism）——同一个操作在不同子类里有不同的表现形式

2.发现泛化的方法

在说明这种关系时使用短语“可以是”（can be）和“是一种”（is a kind of）

3.说明泛化的方法

一条带空心箭头的实线，由子类指向父类

（六）接口建模

1.接口（interface）

接口没有属性（除常量外）、关联或者状态，只有公共的、抽象的操作
接口与类没有关联
接口可以与另一个接口具有泛化关系（一个接口继承另一个接口）

2.表示接口的方法

使用象征类的矩形加上关键字<<interface>>
在矩形的右上角画一个小圆圈
单独一个圆圈，圆圈下方写上接口名字
类使用接口时用指向接口的一条虚线箭头表示 - - ->，箭头上标有<<use>>
类实现接口时用一条末端带三角形的虚线表示 - - -▷，虚线上标有<<implement>>

接口表示方法

（七）对象建模

1.对象建模的作用

举例描述复杂的类和类之间的关系，用对象的例子（对象图）来阐明

对象图

三、行为规格说明（Behavior Specification）

（一）用例建模

1.用例的本质特性

一个完整的功能
一个外部可见的功能
一个正交的功能
- 正交：用例和用例之间没有冲突、覆盖、交叉和遗漏（不重不漏
- 通过需求依赖矩阵实现
由一个参与者启动的一个功能
给参与者传递确切值的一个功能（有返回值）

2.发现用例的方法

需求文档种标识的需求
系统的参与者以及他们的使用目的

3.说明用例的方法

用例图
- 参与者
- 用例
- 关系
  - 关联：Actor ↔ use_case，表示方法：→或↔
  - 包含：use_case ↔ use_case，表示方法：A—<<include>>→B，A执行B一定执行
  - 扩展：use_case ↔ use_case，表示方法：A—<<extend>>→B，A执行B不一定执行
  - 泛化：Actor ↔ Actor，表示方法：—▷，A—▷B，A是B的一种
  - 依赖：Actor ↔ Actor，表示方法：A - - - <<depends on>> - - -> B，A依赖于B