系统分析与设计复习

PART 1 题型

1. 单项选择题（2分每道，共15道）：考核RUP(Rational Unified Process,统一软件开发过程)以外的知识，如建模、UML diagram、需求工程、UML building block等方面

2. 简答题（4道共25分）：之前说只有3道简答的时候，是RUP2道，软件工程1道，每道题要至少100字，改成4道之后就不清楚剩下一道考什么。由于改成4道，老师说答要点即可。（P.S：为了多拿分，我觉得质量跟不上去的话，数量一定要跟上，能多写就写多点。）
   简答题有一道是考查RUP二维图（4个水平阶段+10个工作流），这个图在课件或者参考书里很常见，考查如何理解的问题。
   还有可能会考到类似的题目是：RUP最佳实践、为什么用RUP不用瀑布等。

3. 填空题（5个空共15分）：考抽象类图+状态图或者是抽象类图+时序图，考查图里面很细节的东西，例如图里的冒号代表什么意思，斜体代表什么意思等等类似的。

   继承关系的滥用判断及修正。

4. 分析题（30分）：一个 problem statement， 然后根据题目给出的 statement，分成4个小问考查。

• （10分）画出用例图（着重用例间关系、参与者间关系）
• （10分）找实体类，画出实体类图，重点是类与类之间的关系，不需要找属性和方法
• （5分）画界面类、控制类、必要的抽象类
• （5分）画时序图

类、接口、创建型扩展机制、关联（分为组合、聚合）、依赖关系、多态、部署图中子系统与包图、接口的联系、区分状态图及活动图、IBM475 中的“责任”的分配、用例间关系（泛化、包含、拓展）、4+1 view。

PART 2 知识点

一、RUP

统一软件开发过程（Rational Unified Process），是一个面向对象且基于网络的程序开发方法论。

（一）四个阶段

1. 初始 Inception - 不是需求分析，而是可行性分析
2. 细化 Elaboration - 不是需求分析或设计过程，而是迭代式实现核心体系结构，缓解高风险问题
3. 构造 Construction - 所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详尽的测试，准备部署
4. 交付 Transition - 测试和部署

（二）6个最佳实践

1. 迭代开发

2. 管理需求

3. 使用基于构件的架构

4. 可视化建模

5. 续验证质量

6. 管理变更

（三）4+1 View

​ 逻辑视图、实现视图、进程视图、部署视图 + 用例视图

二、UML

Unified Modeling Language，统一建模语言，是一门用于对面向对象开发的产品进行可视化建模、说明、架构和文档编制的标准语言。

（一）组成

1. 事物 Things

UML模型中最基本的构成元素，是具有代表性的成分的抽象。

1. 构件/结构：静态部分，概念及物理描述。

   包括：类（对相同对象的描述），对象，接口（元素的外部可见行为，服务的操作集），协作（相互作用），用例（系统的行为，是一组动作序列的集合），构件（物理部件），节点（下图没有”节点“）

   

2. 行为：动态部分，跨越时间空间的行为

   包括：交互（消息集合，涉及消息、动作序列、链接），状态机（状态序列）

3. 分组：组织部分，组织结构

   包括：包（package，将元素组织成组）

4. 注释：解释部分

   包括：注解

2. 关系 Relationships

关系把事物紧密联系在一起。

1. 依赖 dependency - 两个事务之间的语义关系相互依赖

2. 关联 assocition - 结构关系

3. 泛化 generalization - 继承

4. 实现 realization - 由一个类指定另一个的执行契约

   

3. 图 Diagrams

图是事物和关系的可视化表示。

1. 用例图（Use Case Diagram）

   用例图是从用户角度描述系统功能， 是用户所能观察到的系统功能的模型图，用例是系统中的一个功能单元，可以描述用户提出的一些可见的需求或者对应一个具体的用户目标。

2. 类图（Class Diagram）

   类图描述系统中类的静态结构。不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构（类的属性和操作）。类图只是类之间的关系。

3. 对象图（Object Diagram）

   对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。对象图包括一个类和属于该类的对象

4. 时序图（Sequence Diagram）

   顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互。

   用途：表示用例中的行为顺序。

5. 协作图（Collaboration Diagram）

   显示对象间的动态合作关系。

   用途：表示一个类操作的实现。

   协作图和顺序图都表示出了对象间的交互作用，但是它们侧重点不同。

   • 顺序图清楚地表示了交互作用中的时间顺序(强调时间)，但没有明确表示对象间的关系。

   • 协作图清楚地表示了对象间的关系(强调空间)，但时间顺序必须从顺序号获得。

   • 协作图和顺序图可以相互转化。

6. 状态图（State Chart Diagram）

   一个类对象所可能经历的所有历程的模型图。状态图由对象的各个状态和连接这些状态的转换组成 。

7. 活动图（Activity Diagram）

   是状态图的一个变体，用来描述执行算法的工作流程中涉及的活动。活动图描述了一组顺序的或并发的活动。

8. 构件图（Component Diagram）

   构件即构造应用的软件单元。

9. 部署图（Deployment Diagram）

   运行构件实例的安排。

   部署图与构件图有相同的构成元素。

   部署图与构件图的关系：

   • 部署图表现构件实例；构件图表现构件类型的定义。
   • 部署图偏向于描述构件在节点中运行时的状态，描述了构件运行的环境；构件图偏向于描述构件之间相互依赖支持的基本关系。

4. （公共）扩展机制

Extensibility mechanisms

1. 构造型 Stereotype - 新的建模元素
2. 标记值 Tagged value - 新的建模属性
3. 约束 Constraint - 新的建模语义

（二）事物、关系及图示

1. 用例图

Actor、Use Case、关联、包含、扩展、泛化

2. 类图

接口、抽象类、模板类

关联（较弱）、聚合（较强）、组合（更强）、泛化（继承）、实现、依赖（绑定、友元）

ps：双向关联时可省略箭头。

3. 时序图

参与者、对象、生命线、消息符号

4. 协作图

参与者、对象、消息流

消息标签的格式：[前缀] [守卫条件] 序列表达式 [返回值 :=] 消息名（1.1a / [x>=0] 1.2 *[i:=1…n] : x := calc(n ) ）

实例：

5. 状态图

状态、转移、开始（唯一）、结束（不唯一）

实例：

6. 活动图

活动ActionState、起点InitialState、终点FinalState、对象流ObjectFlowState、发送信号SignalSending、接收信号SignalReceipt、泳道SwimLane

迁移Transaction、分支JunctionPoint、分叉Fork、结合Join

7. 构件图

构件、提供的接口、构件实例；实现关系、依赖关系

实例：

8. 部署图

节点、构件、接口、构件实例

实现关系、依赖关系、关联关系、其他关系

三、分析类

它代表问题域中的简洁抽象，应该映射到真实世界的业务概念。

（一）三种构造型

1. 边界类 Boundary

中介本系统与其环境之间的协作。如：用户界面类、系统接口类、设备接口类

2. 控制类 Control

封装特定用例的行为。如：引入控制类来协调过程

3. 实体类 Entity

用于建模事物的永久信息。如：客户 Customer

四、OMT

Object Management Technology，对象管理技术，包括三种模型：

1. Object Model
   描述系统的静态结构，包括：

   对象object，类class，属性attribute，行为action，联系association，关系relationship，聚集aggregation，继承inherit

2. Dynamic model
   描述系统随时间的变化，包括：

   状态state，事件event，状态图state chart

3. Functional model
   系统中的计算功能和函数，包括：

   过程process，数据流dataflow，角色actor，数据仓库data warehouse，控制流control flow，数据流图dataflow chart

五、OOA/OOD

（一）OOA

Object-Oriented Analysis: 面向对象分析法

1. 组成：5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。
2. 结构：在这种方法中定义了两种对象类之间的结构，一种称为分类结构（一般与特殊的关系），一种称为组装结构（对象之间的整体与部分的关系）。
3. 原则：抽象，封装，继承，分类，聚合，关联，消息通信，粒度控制，行为分析
4. 产生模型：OOA产生三种模型，即上文OMT中的对象、动态、功能模型。
5. 步骤：确定对象和类，确定结构，确定主题，确定属性，确定方法

（二）OOD

Object-oriented Design: 面向对象设计法

主要作用是对OOA分析的结构作进一步的规范化整理，以便能够被OOP（面向对象编程）直接接受。

OOD就是“根据需求决定所需的类、类的操作以及类之间关联的过程”。

六、模式

1. Business patterns
   业务模式解决业务领域内的问题，通常是分析情况，例如如何建模和构建包括发票，组织，信息等的业务资源。 业务模式还涉及如何组织和关联业务流程，业务规则，公司愿景和目标。
2. Architectural patterns
   结构模式解决了信息系统架构设计领域中出现的问题，例如如何组织系统内的子系统或如何在最高抽象级别上定义系统实现。
3. Design patterns
   设计模式用于已经映射和描述了分析的情况，并且重点是提供灵活和适应性强的技术解决方案。 已经记录了许多设计模式，用于构建解析器，将对象转换为关系数据库，创建灵活的类层次结构以及更改或扩展代码结构。

七、迭代式开发

（一）定义

迭代是在既定计划和评价标准之下执行的一系列软件开发活动，每次迭代是一次集成的软件开发过程包括测试，并产生一个可执行的软件版本。

（二）好处

1. 迭代可以在大投资前解决可预见的风险。
2. 早期迭代可以获得用户反馈。
3. 连续地测试和集成的开发过程。
4. 客观的里程碑集中在短期。
5. 通过对执行过程的评估来衡量开发进度。
6. 部分可执行部件可被配置。

八、软件架构

（一）定义

计算系统的一个或多个结构，包括软件组件、这些组件的外部可见属性以及它们之间的关系。软件体系结构不仅与结构和行为有关，而且与使用，功能，性能，弹性，重用，可理解性，经济和技术约束以及权衡和美学问题有关。

（二）特性

1. 功能性目标：系统执行其用户所需功能的能力。自然，这通常是最受关注的特征。 除了定义基本功能外，它还涉及寻找简化系统可用性的方法。 在系统上查找功能需求的许多基础都可以从业务模型中获得。
2. 非功能性目标：例如性能，安全性和可用性，并不直接与特定功能相关；相反，它们会影响整个系统。必须将这些特性的支持设计到整个体系结构中。

（三）好的架构的原则

1. 明确定义的子系统，接口清晰。
2. 子系统之间简单且很少的单向依赖性。
3. 独立开发的子系统。
4. 简单清晰的沟通机制和互动模式。
5. 孤立的技术选择。
6. 清晰和同步的并行执行。
7. 轻松可视化和交流。

（四）持久性框架

A persistence framework，一组通用，可重用和可扩展的类型，它们提供支持持久性对象的功能。

通常，持久性服务必须将对象转换为记录（或某种其他形式的结构化数据，例如XML）并将其保存在数据库中，并在从数据库检索时将记录转换为对象。

（五）框架

框架是用于相关功能的一组可扩展对象。 典型的示例是GUI框架，例如Java的AWT或Swing。

• 通常是一组内聚的接口和类
• 包含具体的抽象类
• 通常要求用户定义子类

（六）关键思想

1. 映射Mapping - 类与存储、属性与字段之间必须存在映射。两个架构之间必须存在架构映射。
2. 对象身份Object identity - 对象具有唯一的对象标识符。
3. 数据库映射器Database mapper - 负责物化和去物化。
4. 物化和去物化Materialization and dematerialization - 物化是指将数据从持久性存储转换为对象。
5. 缓存Caches - 持久性服务缓存物化对象以提高性能。
6. 对象的事务状态Transaction state of object - 例如对象是否被修改。
7. 事务操作Transaction operations - 提交和回滚。
8. 懒物化Lazy materialization - 尽在需要时才物化特定实例。
9. 虚拟代理Virtual proxies - 代理实现懒物化。

九、OO面向对象

面向对象（Object Oriented）技术是一系列支持软件开发的原则（抽象，封装，多态性），以及支持这些原则的程序设计语言，数据库和其它工具。

（一）基本原则

1. 抽象：提取出一个实体区分其它类型实体的本质特征，定义外界所能观察到的边界，并不具体表示某个实体，而是表示出其基本特征。
2. 封装：对用户隐藏执行过程。
3. 模块化：将复杂系统分成几个可控制的模块，帮助人们理解复杂系统。
4. 层次：是一种从高到低有确定次序的结构，同一层的元素具有相同的抽象程度。

（二）优点

1. 反映一个特定实例。
2. 有利于构件和代码重用。
3. 更加真实地反映现实世界模型。
4. 具有更好的稳定性。
5. 能适应需求的变化。

（三）缺点

1. 需要一定的软件支持环境。
2. 不太适宜大型的 MIS 开发，若缺乏整体系统设计划分，易造成系统结构不合理、各部分关系失调等问题。
3. 只能在现有业务基础上进行分类整理，不能从科学管理角度进行理顺和优化。
4. 初学者不易接受、难学。

（四）GRASP

一般职责分配软件模式，General Responsibilities Assignment Software Pattern，五种模式：

1. Information Expert

2. Creator

3. Low Coupling

4. Controller

5. High Cohesion

PART 3 例题

一、校园一卡通案例

1. 在华工校园，学生可以申请消费卡，卡管理员会在收到申请后创建一张新的消费卡，消费卡可以在校园超市中使用。当学生用卡消费时，营业员将从卡中扣除钱。另外，卡管理员可以为学生在卡中存钱。想象一下您已经被雇用来开发支持软件。

   • 绘制系统的 UML 用例图。

   • 绘制一个时序图，以模拟使用卡的场景。

   • 绘制系统的类图。

   • 绘制消耗卡类的状态图。

二、大学选课

大学选课系统是与学生有着紧密的联系的系统。学生可以登录该系统选修课程，查看分数。教授可以登录到系统选择课程授课，提交学生成绩。学校另有一个系统里面保存有课程目录信息，选课系统需要和课程目录系统通讯以取得课程目录信息。请对该“大学选课”系统进行面向对象分析并运用 UML 建模设计出 Use-Case diagram。

ANSER：

PART 4 OTHERS

1 域模型建模过程

1. 定义概念类
2. 找到联系
3. 添加属性
4. 建模泛化

2 SSD(System Sequence Diagram) - 为用例场景明确系统事件

3 GoF Patterns

​ 四人组，Gang of Four

1. Adapter
2. Factory
3. Singleton
4. Strategy
5. Composite
6. Facade
7. Observer
8. State