需求分析与系统设计

erpEnterprise Resource Planning
联合应用设计会议(Joint Application Design, JAD)

列表框，组合框

系统开发过程管理

RUP rational unified process 统一软件开发过程
RAD rapid application development 快速软件开发
MSF microsoft sync framework 微软解决方案框架
JAD joint application development 联合应用软件开发
Agile XP、scrum等

views

是表达系统某一方面特征的 UML 建模元素的子集，它是由一个或者多个图组成的对系统某个角度的抽象

Usecase View
描述系统应该具备的功能，即被称为参与者（执行者）的外部用户所能观察到的功能
Logical View
描述用例视图中提出的系统功能的实现
Process View
考虑资源的有效利用、代码的并行执行以及系统环境中异步事件的处理
Implementation View
描述系统的实现模块以及它们之间的依赖关系
Deployment View
显示系统的物理部署，并描述位于节点实例上的运行组件实例的部署情况

UML

unified modeling language 对软件系统实现visualizing,specifying,constructing,documenting
关系：关联、依赖、泛化、实现、聚合

用例图 UseCaseDiagram
类图 ClassDiagram
描述类的内部结构和类与类之间的关系
状态图 StatechartDiagram
来描述类的对象所有可能的状态以及时间发生时状态的转移条件
活动图 ActivityDiagram 是状态图的一种特殊情况
描述了活动到活动的控制流
时序图 SequenceDiagram
描述了对象之间消息发送的先后顺序
协作图 CollaborationDiagram
描述了收发消息的对象的组织关系
组件图 ComponentDiagram
表示系统中组件与组件之间，类或接口与组件之间的关系
部署图 DeploymentDiagram
描述了系统运行时进行处理的结点以及在结点上活动的构件的配置。

StarUML

Software Requirements

以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对未来系统的约束
业务需求Business Requirements 客户对于系统的高层次目标要求high-level objectives ，定义了项目的远景和范畴vision and scope
用户需求(User Requirements) 从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为而不涉及内部特性
功能需求Functional Requirements 系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互
非功能需求Non-Functional Requirements
从各个角度对系统的约束和限制,即质量和性能(quality and performance):
安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性等
业务规则Business Rule 对某些功能的可执行性或内部执行逻辑的一些限定条件
数据定义当客户描述一个数据项或一个复杂的业务数据结构的格式、允许值或缺省值时，他们正在进行数据定义。
约束条件Constraints 系统设计和实现时必须满足的限制条件
外部接口需求External Interface Requirement 描述系统与其所处的外部环境之间如何进行交互

需求获取Requirement Elicitation 通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求
需求分析Requirement Analysis 对收集到的需求进行提炼、分析和审查，为最终用户所看到的系统建立概念化的分析模型
需求规格说明Software Requirement Specification 精确的、形式化的阐述一个软件系统必须提供的功能、非功能、所要考虑的限制条件
需求验证Requirement Verification 以需求规格说明为输入，通过评审、模拟或快速原型等途径，分析需求规格的正确性和可行性
需求管理Requirement Management 在整个项目过程中跟踪需求状态及其变更情况
需求获取的方法一般以开放式问题开始谈话，发现问题；以选择式问题引导；以封闭式问题确认事实；以探究式问题(probing，除了….还有….吗？)发现真实想法

模型和建模

模型

数学模型描述系统技术方面的一系列数学公式
描述模型描述系统某些方面的叙述性的备忘录、报表、列表、文字等
图形模型描述系统的图表或系统某些方面的示意性表示

事件发生在某一特定的时间和地点、可描述并且系统应该记录下来的事情(系统应该响应)

外部事件系统之外发生的事件
临时事件由于到达某一时刻所发生的事件
状态事件当系统内部发生了需要处理的情况时所引发的事件
事件列表

事物传统开发中是构成系统存储信息的相关数据(数据实体) 面向对象开发中是在系统中相互交互的对象(对象)
事物的属性有关事物的一条特定信息
实体关系图EntityRelationshipModelERD 类IDEF1X图
乌鸦脚
 IDEF1X图 IDEF是ICAM DEFinition method 的缩写,是美国空军在70年代末80年代初ICAM(Integrated Computer Aided Manufacturing)工程在结构化分析和设计方法基础上发展的一套系统分析和设计方法。是比较经典的系统分析理论与方法。
IDEF1X是IDEF系列方法中IDEF1的扩展版本,是在E-R(实体联系)法的原则基础上,增加了一些规则, 使语义更为丰富的一种方法。用于建立系统信息模型。

类图

抽象类
具体类
关联类

泛化/具体层次图把类按照从最概括的父类到最具体的子类的顺序进行排列的层次图，有时也被称作继承层次图

相比于聚合(空心菱形)，组成(实心菱形)是对象与部分不可分割的关系。

用例图

用户故事Use Story

好的用户故事应具备的特征：INVEST:Independent,Negotiable,Valuable,Estimatable,Small,Testable

用例Use Case 表示系统所提供的服务或可执行的某种行为，是actor与系统的交互
官方定义：一个用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值
$$ 四大特征\left{
\begin{array}{lcl}
行为序列(sequences of actions)\
系统执行(system performs)\
可观测到的、有价值的结果(observable result of value)\
特定的角色(particular actor)
\end{array} \right.$$

$$ 用例\left{
\begin{array}{lcl}
业务用例\
概念用例\
系统用例
\end{array} \right.$$
不能以步骤作为用例
$$ 用例模型\left{
\begin{array}{lcl}
参与者(Actor)\
用例(Use Case)\
通讯关联(Communication Association)
\end{array} \right.$$
特殊的参与者：系统时钟:

用例粒度用例内涵的大小
边界用例分析工作的范围(组织/系统/领域)

泛化(generalization) 用户共有的基用户或用例共有的基用例(空心三角形箭头指向基用户/基用例)
包含(include) 用例1会用到用例2(箭头属性<< include >>)
扩展(extend) 用例2在某些特定情况下会用到用例1(箭头属性<< extend >>)

泳道图swim-lane diagram 侧重于描述多个参与者的活动之间的交互关系

系统分析-结构化

结构化方法面向过程，分析->设计->编程
结构化、模块化、层次化
结构化分析方法(SA) 将待解决的问题看作一个系统，从而用系统科学的思想方法(抽象、分解、模块化)来分析和解决问题
核心思想:自顶而下的分解(top-down)
定义帮助开发人员定义系统需要做什么（处理需求），系统需要存储和使用哪些数据（数据需求），系统需要什么样的输入和
输出以及如何把这些功能结合在一起来完成任务
$$ 图\left{
\begin{array}{lcl}
数据流图 DFD\
实体-关系图 ERD
\end{array} \right.$$

DFD数据流图DataFlowDiagram 用处理、外部实体、数据流以及数据存储来表示系统需求的图表,可以逐步细化(关联、零层、一层…)
要最小化复杂度，避免信息超量

关联图在单个处理符号中概括系统内所有处理活动的DFD,数据存储不放在这里
零层图将一个系统或子系统的所有DFD片段组合到一个单个的DFD图中，这样的DFD图称为事件分离的系统模型/0层图
黑洞带有输入数据的但并不用其产生输出数据的处理或数据存储
奇迹没有足够数据元素作为输入或产生来源的一个处理或数据存储
结构化语言