前排提醒

这是我根据个人理解整理的SDS课程主要框架和知识，如有错误可邮件叫我更正。
本课程为英文授课，此处用中文梳理知识点，如有翻译理解问题多多包涵。

软件工程系统开发

简介

本课程由荷兰方提斯大学的Ir. Georgiana Manolache授课。

系统开发是创造人工系统以满足预定的需求的一门学科，也是一门艺术。它是一个解决问题的过程，在这个过程中，我们将人类知识库中的适当元素用于创造针对某一问题的新知识，并由此确定问题的解决方案。

系统开发角色

信息系统

信息可以为业务提供动力，而且需要被正确管理。

处理计算机生成的信息与处理人工生成的数据的方式不同。

信息系统包括

业务处理系统 (TPS)
信息管理系统 (MIS)
决策支持系统 (DSS)
专家系统

系统分析和设计 (SAD)

发现问题、机会和目标
分析组织中人为和计算机生成的数据
设计计算机信息系统 (IS)，并解决问题

总目的：找到和解决对的问题

在没有适当规划的情况下建立一个系统，会导致用户的极大不满，并经常导致系统的废弃。用户参与整个系统项目是成功的关键。新技术也推动了对系统分析的需求。

系统分析师

系统分析师是一个分析业务流程和信息系统的人。

需要具备以下品质：

问题解决者
交流者
崇高的道德素养，无论是个人方面还是职业方面
自律，自勉

开发方法 (Development Methodologies)

传统软件开发生命周期 (SDLC)

传统软件开发生命周期分为七个阶段。如下图。

瀑布开发。

敏捷开发

迭代、循序渐进的软件开发方法。

极限开发(XP)，能力成熟度模型(CMM)

五个阶段：

探索
规划
迭代到第一个发行版
Productionizing（不知道怎么翻译，词典上的意思是to make something into a product which can be sold，我找不到中文里比较好的词形容这个。）
维护

十二个准则：

满足客户
欢迎改变
频繁交付
共同工作
信任支持
面对面谈
工作软件（我的理解就是这玩意应该是那种可以看各个人贡献的那种项目管理软件）
持续开发
长期关注
容易维护
自我组织
反思调整

面向对象的软件开发 (OO)

SDLC的替代方法，小规模快速迭代的开发。适用于为应对动态商业环境而快速变化的系统，也适用于持续维护、不断调整和设计的信息系统。

这种方式考验的是系统的对象和组件的严谨性。

统一建模语言(UML)是OO开发的业界标准。

UML的阶段

问题识别
1. 用例图
2. 用例场景
系统分析
1. 活动图
2. 序列图
3. 类图
4. 状态图
系统设计
1. 修改UML图
2. 制定方法规范
3. 开发和记录系统

为什么？

OO的复用、抽象和分离关注点(SOC)让我们的代码更加易懂和易维护。

特点

封装
继承
多态

UML CHEAT SHEET

放图不解释。

组织

组织是旨在通过人员和资源完成预定的目标的系统。

塑造组织的因素

管理水平
组织设计
组织文化

用图形描述系统

内容级数据流图 (DFD)

重点在于流入和流出系统的数据以及对这些数据的处理。外部实体需要排除在系统之外。

实体关系图 (ER)

重点在于组织系统内的实体和它们的关系。可以帮助确定问题的大小和范围。也被系统设计者用来帮助对文件或数据库进行建模。

关系

一对一
一对多
多对多

信息系统 (IS)

信息系统是一个根据一套可预测的逻辑假设将数据处理成信息的系统。

是一个开放系统。

主要组件：

应用
信息技术
人
流程

建模体系 (Modelling Systems)

作用域分析

作用域分析确定了业务概念，这些概念将被细化为信息系统分析模型的组成部分。

作用域范围 (Domain Scope)

作用域范围定义了将一个作用域内的共享活动、规则和概念与外部的共享活动、规则和概念分开的界限。也就是说不属于本软件系统开发范围的东西不碰。

作用域词典 (Domain Dictionary)

记录作用域中所有东西，旨在讲利益相关者和分析师们联系起来。

包括以下方面：

过程
方法
角色
物体 (Object)
业务规则
公式
识别器 (Identifier)

业务规则

业务规则是一套约束企业运作的详细的政策、法律、程序、准则和标准。

事实
推论
触发器
约束
计算

需求收集

一个产品必须具有其客户想要的功能，以实现特定的目标。

需求发现

需求发现确定了系统的范围和主要目标。

需求收集定义了达到这些目标所需要的东西。

需求分类

功能性需求和非功能性需求

管理需求

记录和更新需求
记录来源
将需求分为不同单元
独立识别每个需求
核实需求并记录核实情况
对需求进行优先排序
对需求进行有意义的分类

行为建模

包含用例建模。

用例是系统行为的一部分
用例正式确定了利益相关者和系统之间互动
用例详细描述了利益相关者与系统的互动，以完成对利益相关者有价值的目标
用例是技术独立的

优势：

以用户为中心的技术，从用户的角度捕捉需求。
易于理解，为与其他团队（如市场）、客户和用户的沟通提供了一个很好的方式。
用于功能需求的验证和确认。
通过将项目分解为主要功能，帮助管理大型复杂项目。
作为工作估算、日程安排等的基础。

缺点：

不包含非功能需求。
所有的（子）系统都没有关联角色，有些重要的功能不会被察觉。
可能会导致实体对象和类的过度创建，以及功能过度分离。
不太正式的语言可能会导致验收测试出现问题，因为没有充分定义验收标准。

这个阶段需要产出：

用例总结
内容图
用例图

结构建模

包含UML图。

动态建模

描述了一个系统的内部行为。

序列图

序列图表示参与单一用例或场景的对象的图形化描述。每个步骤都被分为一个独立的阶段。

帮助完善用例描述
帮助寻找参与对象
帮助确定类的责任
帮助确定对象之间必要的通信
可以帮助完善子系统的接口

状态图

用于描述一个对象在响应事件时的状态转换序列
可以帮助识别重要的对象属性
可以帮助完善一个对象的行为描述
应该把重点放在影响对象行为的重要属性上

交互图

合作图

活动图

设计模式

抽象工厂模式

是一种创建型模式。

无需指明具体的类就可以创建有相关对象的簇。适用于当客户无法预料到要实例化的类群时。

组合模式

是一种结构型模式。

将对象“组合”成三个结构以表示部分-整体的层次。适用于客户应该忽略对象的组合和单个对象之间的区别时。

命令模式

是一种行为型模式。

封装来自一个服务的请求。适用于需要用一个要执行的动作来参数化对象时。

用户界面 (UI)

界面设计原则

必须考虑到用户需求、经验和能力。
设计者必须遵从人类的生理和心理规律设计界面，需要提前意识到用户可能会犯的错误。
UI设计原则以平面设计原则为基础，尽管不是所有的原则都适用。

SDS基础知识梳理