步骤(瀑布模型 water model)
1. 项目规划(计划)
2. 需求分析
3. 系统设计
4. 实现与部署
5. 软件测试
6. 运行管理
其实, 大部分的软件模型都是以瀑布模型为基础, 再稍加改动. (可以参考另一个blog, 查看所有的软件设计模型)
另外还有很多软件开发模型, 这里推荐一个 增量模型, 个人在使用
增量模型, (incremental model)
软件被作为一系列的增量构建来设计, 实现, 集成和测试, 每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成, 增量模型在各个阶段并不交付一个可运行的完整产品, 而是交付满足客户需求的一个子集的可运行产品. 整个产品被分解成若干个构件, 开发人员逐个的构件, 最后达成交付产品.
个人感觉增量模型比较好, 也在采用中.
DFD
画数据流图 DFD 注意事项:
1. 不要过早陷入具体的细节
2. 从整体或宏观入手分析问题, 如业务系统的总体结构, 系统及子系统的关系.
3. 通过图形化的模型对象直观地表示系统要做什么, 完成什么功能.
4. 模型对象不涉及太多技术术语, 便于用户理解模型
DFD 建模方法的核心是数据流, 首先抽象出具体应用的主要流程, 然后分析其输入, 如其初始的数据有哪些, 这些数据从哪里来, 将流向何处, 又经过了什么加工, 加工后变为什么数据, 这些数据流最终将得到什么结果. 通过对系统业务流程的层层追踪和分析把要解决的问题清晰的展现及描述出来.
DFD 方法由 4 种基本对象组成 数据流, 处理, 数据存储 和 数据源/数据终点.
注: 上图中的符号没有关系, 因为每本书所用的符号不一样, 但是设计思路, 内容是一样的
DFD图 的设计过程, 也是一个逐步细化的过程: 例如:
1. 先是一个有输入, 有输出, 然后一个大的系统
2. 大的系统再细分成若干子系统
3. 若干子系统再细分为更细微的子系统
另外, 检查数据流图中的每一个元素标有名字, 且层次图易于理解, 其次自顶向下检查数据流图, 保证能够通过编号识别父图与子图之间的对应关系, 然后检查数据流, 要求在较高层次上出现的信息流(图中箭头表示的信息), 在分解后的较低层次中必须出现, 最后检查处理, 保证每个处理至少有一个输入数据流和一个输出数据流.
ER图 ?
联系分类:
1:1 对于实体集A 中的每一个实例, 实体B中至多有一个实例与之联系, 反之亦然.
1:n A 中的每个实例, B 中可以有多个与之联系, 但是反之则不行, 只能有一个与之对应, 如果反之亦然, 那么就是 m:n 的关系了
m:n 应该通过设计的改变等等, 尽量避免这种情况出现.
转载
以自底向上设计概念结构的方法为例，它通常分为两步：
第一步：首先要根据需求分析的结果（数据流图、数据字典等）对现实世界的数据进行抽象，
设计各个局部视图即分E-R图。
第二步：集成局部视图。
概念结构是对现实世界的一种抽象，一般有三种抽象：
⑴分类 （ is member of ）
⑵聚集 ( is part of)
⑶概括 (is subset of )
设计分E-R图的步骤是：⑴选择局部应用
在需求分析阶段，通过对应用环境和要求进行详尽的调查分析，用多层数据流图和数据字典描述了整个系统。
设计分E-R图的第一步，就是要根据系统的具体情况，在多层的数据流图中选择一个适当层次的（经验很重要）数据流图，让这组图中每一部分对应一个局部应用，我们即可以以这一层次的数据流图为出发点，设计分E-R图。
一般而言，中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层数据流图作为设计分E-R图的依据
⑵逐一设计分E-R图
每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，
<1> 标定局部应用中的实体, <2> 实体的属性、标识实体的码， <3>
确定实体之间的联系及其类型（1：1、1：n、m：n）。
<1> 标定局部应用中的实体
现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是 "is member of
"的关系。例如在学校环境中，可以把张三、李四、王五等对象抽象为学生实体。
对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是
"is part of "的关系。例如学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码。
<2>
实体的属性、标识实体的码
实际上实体与属性是相对而言的，很难有截然划分的界限。同一事物，在一种应用环境中作为 "属性
"，在另一种应用环境中就必须作为 "实体 "。一般说来，在给定的应用环境中：
⑴属性不能再具有需要描述的性质。即属性必须是不可分的数据项。
⑵属性不能与其他实体具有联系。联系只发生在实体之间。
<3> 确定实体之间的联系及其类型（1：1、 1：n、 m：n）。
根据需求分析，要考察实体之间是否存在联系，有无多余联系
（二）、 合并分E-R图，生成初步E-R图。
各分E-R图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。
1．属性冲突 (1)
属性域冲突，即属性值的类型、取值范围或取值集合不同。
例如：属性“零件号”有的定义为字符型，有的为数值型。
(2)
属性取值单位冲突。 例如：属性“重量”有的以克为单位，有的以公斤为单位。
2．命名冲突 (1) 同名异义。 不同意义对象相同名称。
(2) 异名同义（一义多名）。同意义对象不相同名称。“项目”和“课题”
3．结构冲突
(1)
同一对象在不同应用中具有不同的抽象。例如 "课程 "在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。
(2)
同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。
(3) 实体之间的联系在不同局部视图中呈现不同的类型。
例如实体E1与E2在局部应用A中是多对多联系，而在局部应用B中是一对多联系；又如在局部应用X中E1与E2发生联系，而在局部应用Y中E1、E2、E3三者之间有联系。
解决方法是根据应用的语义对实体联系的类型进行综合或调整。
（三）．修改与重构，生成基本E-R图
分E-R图经过合并生成的是初步E-R图。之所以称其为初步E-R图，是因为其中可能存在冗余的数据和冗余的实体间联系，即存在可由基本数据导出的数据和可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，因此得到初步E-R图后，还应当进一步检查E-R图中是否存在冗余，如果存在，应设法予以消除。修改、重构初步E-R图以消除冗余，主要采用分析方法。除此外，还可以用规范化理论来消除冗余。