02376信息系统开发
2025-01-08 15:11:09 0 举报AI智能生成
信息系统开发是一个复杂的过程，涉及到多个阶段的工作。首先，需要进行需求分析和设计，确定信息系统的目标和功能。接下来，进行系统架构和详细设计，包括数据库设计和接口设计。然后，进行编码和测试，确保系统的正确性和稳定性。最后，进行系统集成和部署，将系统部署到实际的运行环境中。在这个过程中，需要使用各种开发工具和技术，如Java、Python、数据库技术等。生成的文件包括需求文档、设计文档、源代码、测试用例等。
作者其他创作
大纲/内容
第1章 信息系统开发概述
1.1 信息系统的基本概念
信息系统与技术
信息系统
最早由明尼苏达大学教授Davis于1985年提出：信息系统是一个利用计算机软硬件和数据库的人机信息系统
我国薛华成教授认为：信息系统(Information System IS) 是一个以人为主导，利用计算机技术和网络通信技术以及其它办公设备的集成化人机系统
信息系统九大要素
目标：是信息系统建设的根本出发点和最终目的
边界：是不可见的，很难从物理角度区分，系统间通过接口连接
构件：系统的组成模块或子系统
构件之间的关系：子系统之间相互依赖，协同工作
环境：包括用户环境、技术环境、法律环境
接口：一是与其它系统之间的接口，二是与人之间的接口（用户界面）
输入：需要录入到系统中的数据和信息
输出：软输出（计算机屏幕呈现）硬输出（分发给用户的各类文档）
约束：开发及应用系统的各类限制（技术限制、容量、内存...）
信息技术
指信息采集、存储、加工、输出、传递等过程中的技术总称，包括计算机技术和通信技术（ICT）
技术应用：包括计算机软硬件、网络和通信技术、应用软件开发工具等
系统方法
用系统的观点来认识和处理问题的方法
整体性：分析处理问题过程中，把整体放在第一位
结构性：系统思维时，系统内部结构的合理性
关联性：系统由各种因素构成，具有重要意义的称为构成要素
功能性：使系统呈现最佳状态，调整或改变系统内部功能与作用
信息系统结构
功能结构
输入功能：决定系统所能达到的目的，及系统能力和信息环境的许可
存储功能：系统存储各种信息资料和数据的能力
处理功能：对输入做出系统响应，包括信息传输、加工和存储
输出功能：面向使用者，使用者利用输出信息进行决策
反馈与控制功能：对构成系统的各种信息处理设备进行控制管理，使系统可以自我调整
应用结构
企业信息系统
横向结构
财务子系统
人事子系统
市场子系统
供运子系统
生产子系统
纵向结构
信息系统类型：信息服务的对象
战略管理层系统：高层管理者
战术管理层系统：中层管理者
知识管理层系统：知识工作者
操作管理层系统：操作管理者
软件结构
指支持信息系统各种功能的软件系统组成的系统结构，采用功能-层次矩阵表示
信息系统类型
按用户类别分为前端和后端信息系统
按功能、服务组织层次分为
事务处理系统（TPS）
面向数据，以处理数据为核心，针对某一只能制成一个独立系统
工作原理
数据收集
数据校验
数据修改
数据处理
数据存储
文档生成
典型的事物处理系统
超市POS系统
教务信息系统
航空公司订票系统
图书管理系统
管理信息系统（MIS）
面向信息，以生成有用信息为核心，包括上下层职能系统
工作原理
通过获取组织内各事物处理系统输入的数据，按设定的报表格式处理后，向管理者提供业务反馈信息
特点
支持操作层和管理层的结构化决策
面向报表和提供对业务工作的控制
报表缺乏灵活性，不支持自定义格式
管理信息系统只针对企业内部
信息需求是已知和稳定的
办公自动化系统（OAS）
涵盖企业日常行政的方方面面，旨在提高工作效率
组成部分
工作流
协同工作
知识管理
公文处理
行政办公
知识工作系统（KWS）
帮助组织中工人建立和集成新的知识的信息系统
特征
支持工人方便获取所需的知识库
支持信息系统读取更多的外部数据信息
提供更加有力的处理软件
有较强的运算能力
有友好的用户接口
需要使用工作站
决策支持系统（DSS）
辅助决策者通过数据、模型和知识，以人机交互方式进行半结构化或非结构化决策的计算机应用系统
组成部分
用户界面管理模块
模型管理模块
数据管理模块
特点
支持决策者进行决策分析，不能代替决策者进行决策
可用于各种结构化问题，但重点在半结构化问题
可对各层管理进行支持，但重点在于较高层次
主要应用数据和模型进行决策分析
人机交互（用户界面）
经理信息系统（EIS）
主要服务对象为企业经理，基于DSS和MIS系统，满足经理战略信息需求
特征
使用数据仓库支持决策制定
允许管理人员向下挖掘得到详细信息
灵活的报表数据表达形式
不同类型信息系统之间的联系与区别
信息系统生命周期
3个阶段
开发阶段
构造系统：系统规划、分析、设计与
实施阶段
运行维护阶段
开发和实施占用20% 系统维护占用80%
1.2 信息系统开发过程
系统规划
是开发的起始阶段，也是组织战略规划的组成部分
主要4个方面
确定信息系统和项目的优先顺序
组建信息系统项目团队
确定信息系统项目范围
启动项目
系统分析
根据系统规划书确定的范围，明确用户需求和解决方案并建立逻辑模型
主要2个阶段
需求理解
需求表达
系统设计
根据系统分析说明书要求，设计新系统的技术蓝图
设计主要5个内容
体系架构设计
详细设计
数据库设计
输入输出用户界面设计
代码设计
系统实施
目标是将设计阶段和结果，在计算机和网络上具体实现，将设计文档变成能在计算机上运行的软件系统
主要任务
配置系统运行的软硬件环境
选择合适的开发工具
软件编程与测试
数据库建立与测试
系统转换、系统交接
用户培训
系统运行与维护
系统试运行结束后进入运行与维护阶段
工作任务
技术支持
系统维护
软件升级
1.3 信息系统的相关角色
开发与用户
细分
所有者
用户
分析员
设计员
构造人员
网络搭建、安装数据库、安装软件、编写程序
应用程序员、系统程序员、数据库程序员、网络程序员、安全管理员、web站点管理员、软件集成员
项目经理
第2章 信息系统开发路线、方法与工具
2.1 信息系统开发路线概述
信息系统开发是一个庞大的系统工程，涉及组织架构、管理模式、生产加工、经营管理、数据收集与处理、计算机硬件管理与应用、软件系统开发、人力资源协同
开发路线不唯一
模型驱动开发路线
快速应用开发路线（RAD）
商用软件开发路线
混合开发路线
2.2 模型驱动开发路线
强调采用模型对系统进行可视化的分析与设计
三类开发方法
面向过程
以数据在系统重的处理过程为核心，重点搞清楚系统要怎样处理
两种形式
面向业务过程
面向数据处理过程
结构化方法（SSAD）
20世纪90年代较为流行的开发方法
基本思想：用系统工程的思想和工程化的方法，按用户至上的原则，结构化、模块化、自顶向下的对系统进行分析与设计
特点
严格区分工作阶段
强调开发过程的整体性
充分预料可能发生的变化
工作文件的标准化和文档化
缺点
系统开发周期长
方法是线性而非迭代或递增的
客观世界的问题领域系统可理解性差，软件结构与问题领域结构存在不一致矛盾
系统的可维护性和稳定性差
面向数据
强调完整详细的分析数据和数据之间的关系
信息工程方法
在企业中进行规划、分析、设计和实施应用的体系化方法
主要思想
所有信息系统开发建设不以处理为中心，应该以数据为中心
数据结构是稳定的，而业务流程是多变的
最终用户必须真正参加信息系统的开发
面向对象
流行于2000年后，由统一建模语言UML标准的制定而广泛应用
特征
封装性
将对象作为一个独立的实体，外部可以了解功能，内部细节隐蔽
继承性
对象和类之间的层次结构具有继承关系
多态性
对象之间具有统一、方便、动态的消息传递机制
优点
无缝衔接
开发效率高
容易维护
容易扩展
2.3 快速应用开发路线
是一种开发策略，将系统开发 组织成研讨会，让系统所有者、用户、分析员、设计人员、构造人员一同参会，通过迭代构造方法加速需求分析和设计过程，让用户可以提前看到可以工作的系统，进而提出改进意见，不断优化
优点
鼓励用户和管理层主动参与，增加用户对项目的热情
项目具有较高的可视性和支持度
在原型中可以更早发现错误和遗漏
测试和培训是基本原型方法的一个副产品
缺点
鼓励编码、实现和修改，可能会增加成本
简化了问题分析，有可能导致错误问题
原型容易导致先入为主，不利于分析员考虑其它有价值的技术方案
对速度重视可能会对质量造成伤害
应用场景
快速应用开发适用于用户需求不明确，同时规模不大的项目
两种开发方方法
迭代式开发
通过各阶段的迭代设计缩短开发系统时间，在每次循环迭代中，都要构造和测试一些原型
敏捷式开发
以编程为核心，目的是根据迅速变化的需求快速开发软件，敏捷开发包括：
极限编程（XP）
SCRUM
水晶方法
特征驱动软件开发（FDD）
自适应软件开发（ASD）
动态系统开发（DSDM）
2.4 商用软件开发路线
为了实现业务需要，必须选择套装软件方案，“你得到你想要的，然后付费”
两种方式
购买现成商用软件，直接应用
购买步骤
需求分析阶段进行技术市场调研
参考供应商提交的软件方案的建议，根据需求说明书的业务需求进行评价
与供应商协商软件合同，以及安装和维护软件需要的服务合同
购买软件后，进行差距分析确定软件包功能不能满足哪些业务
安装并测试基本软件
优点
不需要参与大量的编程工作
软件开发费用平摊到购买软件的客户，降低开发成本
购买商业软件有较好的售后技术支持服务
购买通用软件可以减少企业的重复开发
缺点
商用软件依赖软件供应商的长期迭代维护
购买的软件很少能满足业务个性化需求
购买软件不利于业务调整
购买软件包，进行二次开发应用
需求场景
需要开发的系统功能都是一些通用功能
缺少内部开发人员
开发系统属于微机系统
优点
缩短开发时间
可以得到较好的维护
可以减轻企业内部对系统开发的阻力
缺点
功能较为简单
难以满足特殊要求
实施费用随客户工作量增大而上升
2.5 选择合适的开发路线与方法
参照原则
用户需求的明确性
快速应用中的原型、XP方法
对技术的熟悉程度
抛弃式原型方法
系统的复杂性
抛弃式原型方法
系统的可靠性
抛弃式原型方法
项目进度
RAD和敏捷方法
进度可视性
RAD方法
2.6 自动化工具与技术
CASE定义
是一种自动化或半自动化的方法，狭义理解是一组工具和方法的集合，目的是减少重复的工作量
CASE工具分类
需求分析工具
软件设计工具
数据设计工具
项目管理工具
程序设计和代码生成工具
测试工具
基于CASE的系统开发过程
数据生成
从信息建模到数据库设计，根据CASE中的数据定义生成数据库定义
应用生成
从功能建模到应用定义，根据CASE中的应用定义生成应用代码
CASE工具特点
系统开发过程中的手工作业实现自动化
具有合法性检测功能，可校验数据流图和数据的一致性
包括原型法的功能，可帮助分析员绘制人机界面或报表布局
CASE的信息储存库，存储分析员在项目开发中的所有信息
加快软件开发速度，简化软件开发的管理和维护
CASE局限性
只是一种辅助开发工具，在实际开发中必须依赖一种开发方法
无法自动生成具有特定功能的系统，无法实现数据库和第四代语言之间的接口
不能自动进行系统分析
2.7 其它CASE自动化工具
PowerDesigner
Sybase公司的CASE产品，PD系列产品提供了完整的建模解决方案
第3章 信息系统项目管理
3.1 信息系统项目管理生命周期
项目管理贯穿系统开发的4个阶段
项目发起
项目经理评估项目的规模、范围和复杂性，并建立支持后续的活动任务
成立项目团队
建立客户关系
制定项目发起计划
建立管理规程
建立项目环境和工作手册
项目规划
需要弄清楚定义项目的各项活动任务
描述项目范围、候选方案、可行性
将项目分解为可管理的任务
估算资源并创建资源规划
制定初步进度
制定通信计划
确定项目标准和规程
识别和评估风险
创建初步预算
开发工作陈述
建立基线项目计划
项目执行
主要在系统分析、设计和实现阶段执行
执行基线项目计划
按照基线项目计划监督项目进展
管理基线项目计划的变更
维护项目工作手册
沟通项目状况
项目终结
当需求项目完成并且是成功的，则可以终止
结束项目
项目评估
终止项目合同
3.2 项目组织
常见的三种项目组织形式
单纯型项目组织
特点
项目小组成员全部投入项目
优点
项目经理对项目拥有完全自主权
成员只需要面对一个老板
沟通层短，决策快
荣誉感和使命感高
缺点
资源浪费，人员与设备无法共用
组织目标和策略容易忽略
职能部门和新科技脱节
项目小组成员完成项目即解散，容易导致项目延误
职能型项目组织
特点
项目建立在职能部门之中
优点
成员可以同时参与多个项目
成员有机会升迁
职能部门中有大量专业人员处理技术问题
缺点
项目中与职能部门无相关性的地方容易忽略
客户需求容易被忽略
矩阵型项目组织
特点
项目成员由不同职能部门提供，项目经理决定工作内容和完成时间，职能部门经理控制人员和技术
优点
强化与职能部门的沟通
项目经理对项目负成败责任
降低资源重复
可以执行上级组织政策
项目可获得较多支持
缺点
受职能部门和项目组的双重管理
项目经理需要较强的沟通技巧
项目组成员不容易全心投入项目
3.3 项目管理技术
工作分解结构（WBS）
将项目层次化分解成开发阶段、开发活动和开发任务
分解方式
按功能模块分解
按系统开发过程的不同阶段分解
按项目地域或部门分解
按项目目标或职能分解
WBS图形化表示方式
绘制类似组织结构图的自上而下的层次图
最低层的项目交付成果称为工作包，工作包定义的交付完成时间遵循：80小时法则、两周法则
甘特图
一种直观的进度计划方法，采用直线线条在时间坐标上标示单项工程内容进度，，线段起点和终点分别对应子任务的开工时间和完成时间，线段长度表示完成任务所需时间
优点
能清楚表达活动的开始时间、结束时间和持续时间
使用方便，制作简单，应用广泛
除了安排时间，还能与劳动计划、资金计划相结合
缺点
很难表达工程活动之间的逻辑关系和依赖关系
工程活动之间前后顺序关系，不确定提前或推迟会对哪些活动有影响
不能表示活动的重要性
不能用计算机对工程进行工期计算
应用范围
活动少的小项目
项目初期工程作总体计划
上层管理者需了解总体计划
作为网络分析输出结果
计划评审技术（PERT）
一种科学的计划管理技术，广泛应用于项目管理
应用步骤
根据工作分解结构列出计划期内的任务
安排任务的顺序，确定任务之间的依赖关系
估算完成任务所需要的时间
根据每个任务最早开始、最晚开始、结束时间、富余时间，计算每个任务时差，找出影响工期的关键任务
第4章 需求获取
4.1 系统需求概述
需求获取的重要性
需求获取是问题和解决方案之间的桥梁，实质是分析员理解项目中描述的客户需求
影响用户需求确定原因
用户不明白他自己需要什么
用户不断更新所提问的需求
用户与分析员之间缺乏有效沟通
用户缺乏技术上的知识
用户缺乏对软件开发的知识
系统需求分类
用户角度（解决用户问题）开发角度（满足正式文档需具有能力）
需求三层次
业务需求
反映组织或用户对系统高层次的目标要求
用户需求
用例文档中说明用户使用产品必须完成的任务
功能需求
定义系统必须实现的软件功能
4.2 需求获取过程
主要获取途径
通过与用户对话或观察用户收集的信息（访谈手稿、文档笔记、会议纪要）
现有的书面信息：业务战略陈述、业务表格、文档报告、演示范例、规程手册、培训手册、流程图
基于计算机信息：应用设计会议结果、支持系统会议文件、系统CASE资料库内容、系统原型报告
获取需求的活动
了解用户需求
项目计划阶段已经界定项目范围，在此基础上进行需求获取
识别系统用户
用户调研与访谈
访谈结果整理
访谈结果呈现
分析用户需求
分析已经收集到的需求，找出其中不足之处
是否遗漏重要的需求
是否存在矛盾需求
是否存在重复需求
是否存在模棱两可需求
是否存在不可行需求
编写需求文档
需求获取阶段的主要成果，包括用户的功能需求和非功能需求（需求规格说明）
系统应该提供的功能和服务
系统非功能需求，包括的系统特征、性能和属性
系统开发或者运行必须遵守的约束条件
系统与其他系统之间的接口
评审需求文档
用户评审和同行评审
需求管理
需求变更
提出变更请求
变更影响分析
变更批准
变更执行
变更测试
变更结束
需求跟踪
目的是建立和维护“需求-设计-编程-测试”之间的一致性
4.3 需求获取的方法
收集系统需求的传统方法
访谈
观察
名义团体技术
文档与报告
联合应用设计
原型
第5章 过程建模（结构化分析）
5.1 建模过程概述
逻辑模型是描述系统是什么和做什么的非技术性图形化表示，也称为概念模型或业务模型
5.2 数据流图（DFD）
是过程建模的一种工具，用于分析、描述信息系统的数据转换和流动状况，概括描述系统内部逻辑，是理解表达用户需求与用户沟通的工具
数据流程图的4个组成部分
外部实体
与系统交互的外部人员或其它系统，也称为源点/终点
用方形框表示，框中写上外部实体名称
处理过程
指对输入数据流或条件作出响应的工作，即对数据进行处理转换
系统处理大致划分三类
功能过程
事件过程
基本过程
用带圆角长方形或圆形表示
数据流
是一个过程的数据输入或数据输出，是流动中的数据
用实线箭头表示数据流，用虚线箭头表示非数据流
数据存储
保存数据的地方，用来存储静止的数据（个人、小组、地点、对象、事件、概念）
用右边开口的长方条表示，或两条平行线
数据流图的绘制
绘制思想：自上而下，逐步细化，直观清晰，简单明了
分层数据流图
顶层图（系统边界，输入输出数据流）
0层图（将顶层图系统分解成若干子系统，从0开始编号）
中间层图（对上层父图细化，形成子图）
底层图（无需分解的基本处理）
数据流图规则（P101）
命名规则
每个元素都要命名
每个元素能反映其属性
每个元素名字是唯一标识
过程
一个对象没有过程只有输出，那一定是外部实体
一个对象没有过程只有输入，那一定是外部实体
不允许过程输入与输出之间毫无关联
过程的输入应有别于输出
一个过程采用动词标记
数据存储
数据不能从数据存储之间流入
数据不能从外部实体流到数据存储
数据不能从数据存储流到外部实体
数据存储采用名词标记
外部实体
数据不能从外部实体之间移动，需由过程移动
外部实体采用名词短语标记
数据流
在标记符之间只能单项流动
同样数据不同版本流到不同地点
不能直接流回流出的同过程
流入数据存储的数据流表示更新
流出数据存储的数据流表示检索
数据流采用名词标记
数据流图的分解
从一个系统到4个组成过程的行动称为功能分解，功能分解是将系统视角分解成为细化的详细过程
数据流图的平衡
在对DFD分解时，必须将输入和输出保留到下一层分解的过程中
5.3 过程逻辑
数据流图是确定过程有效的工具，它直观描述系统中数据的流动和变化；过程逻辑表述方法主要分三种：结构化语言、决策表和决策树
结构化语言
基于自然语言发展的一种规范化语言语法，分为内外两层，外层描述控制：采用顺序、选择、循环三种结构；内层采用自然语言短语
决策表
又称为判断表，是一种表格状的图形工具，适用于描述条件较多，有多种决策方案的情况
结构化语言表示信息系统过程包含逻辑，但逻辑复杂时，图形比结构化语句更加清楚
决策表三部分
条件段
包含所建模的各种条件
行动段
包含条件段中值的组合产生的所有行动路线
规则
将条件与行动联系起来的部分就是规则
构造决策表的步骤
命名条件以及每个条件所取的值
命名所有可能出现的行动
列出所有可能的规则
创建表是，替换第一个条件的值
为每个规则定义行动
简化决策表
决策树
又称为盘点数，是一种树状的图形工具，事故描述处理中有多种策略，要根据若干条件判定来确定策略的情况
结构化语言、决策表和决策树的选择
顺序和循环动作，选择结构化语言
多个条件复杂组合，选择决策表或决策树
决策树比决策表直观，决策表逻辑验证更严格
5.4 数据字典
定义和说明数据流程图中每个成分的工具；包括数据项、数据流、数据存储、处理功能、外部项等逻辑内容和特征
生成数据字典的两种方法
手工生成
优点：具有较大灵活性和适应性；缺点：效率低，编辑困难，容易出现疏漏和错误
计算机辅助生成
优点：具有查询、维护、统计、分析功能
主要包括两类数据
动态数据（可在系统内外流动的数据）
静态数据（不参与流动的数据存储）
创作字典主要内容（P112）
数据项
也称做数据元素，是数据的最小组成单位
数据结构
描述数据项之间的关系，由数据和数据结构组成
数据流
由一个或一组固定的数据项组成
过程字典
针对数据流图中最底层的过程逻辑，用来说明DFD中基本过程逻辑
数据存储
数据结构保存的地方
第6章 数据建模
6.1 数据建模相关概念
是一种组织和记录系统数据的技术，为数据库定义业务需求，数据模型最终要转换数据库，因此也称为数据库建模
E-R图
数据模型典型代表，“实体-关系模型”（Entity-Relationship）用于描述现实信息世界中数据的静态特性，而不涉及数据的处理过程
E-R模型是用户和数据库设计人员之间进行交流的工具，表示业务环境中实体、实体之间联系以及实体和联系的属性
E-R模型基本元素：实体、属性和联系；采用Martin符合记法
实体
实体与实例
实体是用户环境中的数据对象（人、地方、对象、事件或概念）实例是实体中的一个特例（订单编号）
属性
描述实体的特征
特性：默认值、数据类型、取值范围、主码(标识符)、候选码
关系
也称为联系，是在一个或多个实体之间的业务联系，双向连接线表示一个关系，动词描述该关系
联系的度是参与该联系的实体类型的数量
E-R模型常见的三种联系
一元联系（度为1）
也称为递归联系，是一个实体类型的实例之间的联系
二元联系（度为2）
两个实体类型的实例之间的联系，数据建模出现最多的联系类型
三元联系（度为3）
三个实体类型的实例之间同时发生的联系
6.2 逻辑数据建模过程
确定基本实体
在了解数据需求的基础上进行，数据获取主要通过调查和提问方式进行
建立实体间的关联
识别基本实体后需要建立实体之间的联系，并确定实体实例的基数
确定主码和属性
主码的值不会发生改变
主码的值不能为空
确保主码的值是有效的
尽量不能使用智能码
6.3 规范化
好的数据模型设计标准
是简单的
是无冗余的
是灵活的
第一范式
设R是一个关系范式，R的所有属性都是不可再分的最小数据项，则称R满足第一范式，记为1NF
第二范式
如果R是第一范式，且非主属性都完全依赖主码，则称R满足第二范式，记为2NF
第三范式
如果关系模式R是第二范式，且所有非主属性对任何主码都不存在传递依赖，则称R满足第三范式，记为3NF
6.4 数据-过程模型映射
数据模型和过程模型代表同一个系统的不同视图，但有相互关联；在数据模型中每个实体在过程模型中有一个数据存储
采用数据-过程-CRUD矩阵，进行数据模型与过程模型的同步质量检查
第7章 应用架构设计
7.1 架构概述
应用架构是一个用于实现信息系统的软硬件和网络的设计蓝图，确定软件及数据使用哪些硬件和网络
应用架构与框架
应用架构是一个逻辑性的框架描述，通常由一个设计思想，加上若干设计模式，再规定一系列接口规范、传输协议、实现标准等文档组成
架构的逻辑层次
信息系统的5个逻辑分层
表项层
呈现给用户的界面
表项逻辑层
与用户交互的组件
应用逻辑层
业务逻辑层
数据处理层
存储和访问数据库所需的所有命令和逻辑
数据层
数据库中实际存储的数据
7.2 典型的系统应用架构
基于主机的服务器架构
最早的计算架构，主机完成所有功能；用户在终端发送和接受来自服务器的消息
优点
简单，运行性能良好
缺点
服务器执行所有消息，随着请求越多，响应越慢
文件服务架构
是一种基于局域网的方案，服务器计算机仅装载数据层，其它层都在客户端实现逻辑处理
系统响应用户请求逻辑
客户端向计算机发出增删改请求某条记录
客户端将指令传到服务端（存储和传输数据）
记录存放服务器上的文件服务器数据库里
在读取时需要将表加锁，直到客户端返回表为止
文件服务器对客户端请求进行响应，返回整张表
客户端对某条记录进行数据处理，并将包含修改记录的表返回服务器
服务器端对文件服务器数据进行修改
文件服务器数据库完成修改后，对整个表进行解锁
客户/服务器架构
是一种分布式计算方案，5个逻辑分层在客户端和一个或多个服务器分布
服务器类型
数据库服务器
Oracle、SQL Server
事件服务器
CICS、BEA
应用服务器
运行信息系统的应用逻辑服务
信息组件服务器
运行电子邮件、日历等服务
服务器
两层客户/服务器架构，C/S结构，运行因特网或内网站点，向客户端返回文档和数据(XML)
三层或N层客户/服务器架构
使用两层架构同样的数据库服务器，并在客户端和服务端之间加入了中间层
浏览器/服务器架构
主要用于网络计算和Web应用，表现层和表现逻辑层使用web服务器实现
相关网络技术
Java、HTML(超文本标记语言)、XML(可扩展标记语言)
7.3 应用架构举例
MVC架构
是Smalltalk语言的架构，可以让程序员迅速建立使用者接口（User Interface）
包括三个抽象类别
Model
负责管理文件资料，对应数个View对象
View
负责解释使用者终端输入的信息，显示Model对象的某一方面，对应一个Controller对象
Controller
根据输入消息要求Model处理文件资料，要求View对象更新画面
架构组成
MVC5层次软件架构
Web
采用structs框架，负责展现数据和人机交互
Business Control
负责处理来自Web的请求
Entity
自研框架，负责业务数据逻辑处理
DB Control
使用Hibernate框架
DB
7.4 应用架构设计内容
进行架构设计时，需要考虑的内容
信息系统集中或分布程度
数据在网络处理器上的分别情况
过程在网络处理器上如何分布
数据架构设计
主要解决数据分布不同服务器的问题，采用数据分割和数据复制两种方式
数据分布策略
单个服务器存储所有数据
不同服务器存储特定表
不同服务器存储特定表的子集
不同服务器复制特定表或子集
过程架构设计（P150）
根据所选择的架构确定相应的软件开发环境
适用两层服务器架构开发环境
PB、VB、Delphi
浏览器/服务器架构软件开发的4个核心标准技术
HTML
XML
CGI（网关接口）
网页编程语言
网络架构设计
主要解决如何将客服端、服务器以及设备分配到网络中，客户端与服务器之间如何连接，用户在哪里与客户端交互等问题
网络架构内容
服务器及其物理位置
客户端及其物理位置
处理器说明
传输协议
第8章 软件过程设计
8.1 过程设计主要内容
总体设计
程序中一个模块完成一个子功能，软件结构可以用层次图或结构图来描述
详细设计
目标是确定怎样具体实现软件结构图中每个模块的具体内容
8.2 软件设计的基本原理
模块化
模块 在程序中是数据说明、可执行语句等程序对象的集合，是可组合、分解和更新的单元
模块基本属性
接口
模块的输入与输出
功能
模块实现什么功能
逻辑
描述内部如何实现要求的功能
状态
模块的主调和被调关系
模块化 指解决一个复杂问题时，自顶向下逐层把软件系统划分成若干模块的过程
抽象与信息隐蔽
抽象是认识复杂现象的过程，即抽出事物本质的共同性，暂时不考虑细节；通过信息隐蔽，定义和实现对模块的过程细节和数据结构的存取限制
模块独立性
为了降低软件系统的复杂性，提高可理解性、可维护性
衡量软件的独立性度量标准
耦合性
块间联系，指软件系统结构中模块间相互联系紧密程度的一种度量
模块耦合性类型
无直接耦合
两个模块间没有直接关系
数据耦合
两个模块间有调用关系
标记耦合
两个模块传递的是数据结构
控制耦合
模块调用传递的是控制变量
内容耦合
最高程度的耦合，也是最差的耦合
公共耦合
通过一个公共数据环境相互作用
内聚性
块内联系，指模块的功能强度的度量
模块内聚性的类型
偶然内聚
一个模块内的各元素之间没有任何联系
逻辑内聚
模块内执行几个逻辑上相似的功能
时间内聚
把需要同时执行的动作组合在一起形成的模块
通信内聚
模块捏所有的元素都在同一个数据结构上操作
顺序内聚
一个模块中各元素都密切相关，且通一功能必须顺序执行
功能内聚
最强的内聚，模块内所有元素共同完成一个功能
8.3 软件设计工具
HIPO图
IBM 于20世纪70年代发明，用图形方法表达系统的输入和输出功能，分层图自顶向下分解系统的模块层次结构
HIPO图
每个矩形框表示一个模块，连线表示调用
IPO图
输入-处理-输出图
软件结构图
和层次图类似，描述软件结构的图形工具，描述模块之间的联系可以用规定的图形符号表示
表示符号
模块
采用矩形框表示一个功能处理模块
调用
箭尾连接主调模块，箭头指向调用模块
数据传递
采用尾端带空心圆的箭头表示
控制传递
采用尾端带实心圆的箭头表示
循环调用
采用带箭头的弧线表示
选择调用
采用菱形框表示
详细设计工具
任务是设计每个模块的实现算法、所需的局部数据结构
常用的3种工具
程序流程图（PFC）
描述程序逻辑结构的工具，与系统流程图类似，区别是箭头符号代表控制流而不是数据流
5种基本控制结构
顺序型
几个连续的处理步骤依次排列构成
选择型
由逻辑判断的取值决定选择处理哪一个
先判定型循环
在循环控制条件成立时，重复执行特定处理
后判定型循环
重复执行特定处理，直到控制条件成立
多情况选择型
列举多种处理情况，根据控制变量的取值，选择一种执行
优缺点
优点：直观清晰，易于使用；缺点：易造成非结构化的程序结构，本质上不是逐步求精的工具
盒图
又称N-S图，根据结构程序设计思想Nassi和Shneiderman提出了盒图
特点
功能域明确（一个特定控制结构的作用域）
不能任意转移控制（盒图没有箭头）
容易确定局部的作用域
容易表现嵌套关系和层次结构
问题分析图（PAD）
1973年日本日立公司发明，用二维树形结构图来表示程序的控制流
优点
支持结构化程序设计原理
支持自顶向下、逐步求精的设计方法
用PAD图表示程序逻辑，易读、易懂、易记
支持程序自动生成
8.4 软件结构设计方法
结构化设计以结构化分析产生的数据流图为基础，按一定的步骤映射成软件结构
变换分析设计
变换流特征
信息沿输入通路进入系统，由外部形式变成内部形式，进入系统的信息通过变换中心处理以后，再沿输出通路变换成外部形式离开系统
事物分析设计
事物流特征
数据沿输入通路到达一个处理T，这个处理根据输入数据类型分解成发散数据流，形成活动路径，并根据输入数据类型在若干动作序列中选出一个执行
综合数据流图映射
包含变换和事物类型的数据流的映射方法
确定DFD整体类型，除明显事物类型都可认为是变换型
把与全局特性不同的局部区域独立出来，确定类型
按整体与局部DFD特性设计软件结构
分层数据流图的映射
8.5 软件详细设计
结构化程序设计
基本思想：在构造任何算法时，采用顺序结构、选择(分支)结构、循环结构作为基本单元，规定结构之间可以并列，但不允许交叉
具有唯一入口和唯一出口，不会出现死循环
程序设计目标
采用程序化设计方法的程序特性
可维护性
可靠性
可理解性
效率高
过程设计方法
一般情况下，程序编写遵循软件工程思想，采用自顶向下的模块化程序设计方法，通过建立软件工程环境提高软件开发效率
自顶向下模块化程序设计注意事项
模块应该具有独立性
模块间相互独立，减少模块间的耦合
模块大小划分要适当
模块包含的子模块数要适合，便于模块单独开发和重构
模块功能要简单
底层模块一般完成一项独立的处理任务
共享的功能模块集中
共享的处理模块，应集中在一个上层模块方便调用
第9章 数据库设计
9.1 逻辑数据模型和物理数据模型
数据库设计前提
在逻辑模型基础上进行物理数据库设计，包括每个属性的物理字段设计，数据量规划等
逻辑数据模型到物理数据模型的转换规则
每个基本实体、关联实体和弱实体都被实现成一个独立表，表名按照DBMS命名规则和大小限制进行格式化
标识主码，并实现为表中的一个索引
每个副码实现为表中索引
对于任何被确定为子集准则的非主属性，应建立索引
标识外键，实现数据模型关系
属性采用字段实现，字段对应表中的列
数据类型：每个DBMS支持不同的数据类型和术语
字段大小：不同DBMS表达实数的精度不同
空或非空：不同DBMS使用不同的预留字显示该特性
域：许多DBMS可以自动编辑数据，以确保数据完整性
默认值
9.2 关系型数据库模型
采用相关联的表或者关系对关系进行描述
一个关系就是一张有命名的二维数据表，每个关系(表) 由几个列与任意多行组成
表中没一列对应关系的一个属性，每一行对应一条记录，一条记录对所有属性都有一个值
9.3 将E-R 图转化成关系
为了比较概念数据模型和所开发的规范化关系，必须将E-R图或类图转化成用关系表示，并与已存在的规范化结合成一个统一的关系集
E-R图转化规范化采用4个步骤
表示实体
实体转换
实体类型的标识符成为对应关系的主码，实体类型其它属性成为关系中的非主码属性
表示关系
关系转换
关系表示依赖关系层次（一元、二元、三元）也依赖关系数量
规范化关系
合并关系
关系合并
逻辑数据库设计的最后一步，将部分冗余的关系合并以消除冗余，整合视图
9.4 设计字段
是系统软件，一个语言或数据库所能识别的应用数据最小单位；逻辑数据库模型的一个属性可能有几个字段进行表示
选择数据类型
数据类型是在表示组织数据时被系统认可的编码方式。对数据存取有很大影响
选择数据类型需权衡4个目标
最小化存储空间
能够表示一个字段所有可能的值
改进字段的数据完整性
支持在字段所有数据操作
运算字段
一个属性经常与其它数据存在相关性；如果一个字段是从其它数据库字段中派生出来的，则称为一个运算(派生)字段
编码与压缩技术
有些属性在很大范围内只取少数几个值，为了节省空间和属性的完整，在编写程序时须对字段进行编码和解码
控制数据完整性
数据完整性控制方法
默认值
范围控制
参照完整性
空值控制
设计文件的控制策略
一个文件不可避免被破坏或丢失，所有设计时需考虑文件破坏后能够被恢复
修复技术
周期性备份文件
将每次更新内容作为处理日志或审查记录存到一个文件中
每一行记录在修改前后都进行保存
9.5 代码设计
代码及其作用
代码是人为确定代表客观事物名称、属性或状态的符号，好的代码可以使机器处理变得十分方便
设计代码的作用
唯一化
规范化
系统化
代码设计原则
必须保证有足够容量
按属性系统化
分类要有一定的柔性
注意分类系统与外系统的协调
代码种类
顺序码
数字码
字符码
混合码
代码设计方法
线分类方法
目前用的最多的一种方法，首先给定字母项，母项下分若干子项，由大集合确定小集合；划分要掌握两个原则：唯一性和不交叉性
特点
结构清晰，容易识别和记忆
对手工系统有较好的适应性
主要缺点是结构不灵活，柔性较差
面分类方法
特点
柔性好，面的增加、删除、修改都很容易
可实现按任意组配面的信息检索，对机器处理有良好的适应性
缺点是不容易直观识别，不便于记忆
代码校验
代码录入容易出现的错误
识别、易位、双易位、随机等错误
避免代码录入错误常用的方法：在设计好代码后，再增加一位检验位
第10章 输入输出与用户界面设计
10.1 输出设计
输出设计目的
信息系统的输出用于向系统呈现信息，输出通常作为管理层和用户最终评估系统价值的基础
输出设计原则
输出应该易于阅读和理解
每个输出应该有一个标题
每个输出应该有日期和时间戳
报告应包括分段信息的节合标题
基于表格的输出，所有字段清晰标上标签
只打印或显示需要的信息
信息应该易于导航和查找
避免计算机行话的错误信息
按时提供输出
制作对用户有意义的输出
选择有效的输出方法
输出方式选择
屏幕显示输出
打印机打印输出
输出格式设计
报表生成器设计
报表是一般系统用的最多的信息输出工具
图形方式
主要采用图片揭示信息
输出设计过程
确定系统输出的需求
输出方式设计和设备选择
输出格式设计
设计、验证并测试输出
输出设计说明
完整输出设计说明书信息
输出信息使用情况
输出信息内容
数据结构、信息形式、数据类型、精度、取值范围
输出格式
表格、报告、图形
输出设备和介质
打印机、显示器
10.2 输入设计
输入设计目的
根据系统目标和用户的特点，确定出使用户满意的输入设计方案；一是确保输入的正确性，二是确保输入的快速高效
输入设计原则
控制输入量
减少输入延迟
避免额外步骤
输入过程尽量简化
减少输入错误
输入方式选择
输入设备
键盘输入
数模转换设备
条形码、扫描仪器、传感器
网络通信输入设备
数字网络、电话网络
磁盘、光盘输入设备
U盘、移动硬盘、光盘
输入格式设计
原始凭证格式设计
输入介质记录格式设计
输入控制与校验
输入测试
类、组合、期望值、缺失数据、图片、范围、合理性、校验位、尺寸、取值
12种常用的检验方法
重复校验
人工校验
检验位校验
控制总数校验
数据类型校验
格式校验
逻辑校验
界限校验
记录计数校验
平衡校验
匹配校验
顺序校验
输入设计过程
输入数据内容的确定
输入方式和设备选择
输入数据的格式设计
输入数据的正确校验
采用原型工具进行输入屏幕设计
10.3 用户界面设计
用户界面是系统与用户之间的接口，也是控制和选择信息输入和输出的主要途径
用户界面设计原则
可交互性原则
用户针对性原则
多种交互方式
提供反馈
状态信息
弹出信息
错误或警告信息
提供帮助
出错处理功能
信息显示原则
用户界面一致性
仅显示当前上下文有关信息
采用窗口分割不同种类信息
界面要安排足够的提示信息引导
应用程序与界面分离
用户界面设计元素
用户常用的单击设备
操纵杆、轨迹球、光笔、触摸屏、鼠标
用户界面常见的标准控件
命令按钮
单选按钮
复选框
文本框
列表框
下拉列表框
表格和网格
用户界面交互方式
指令语言交互
菜单交互
表单交互
基于交互对象交互
自然语言交互
用户界面设计步骤
设计用户界面之间的相互关系及先后顺序
设计用户界面原型
从用户那里获取反馈信息
迭代修改用户界面
第11章 系统实现与运行
系统实现阶段主要工作
系统组件开发
安装与测试
软件包的安装
数据库建立与测试
合理选择计算机网络设备
组建网络系统网络布线和施工
工作环境安装系统
系统交付客户
系统运行和维护
11.1 软件实现
软件编程
编码是设计的进一步具体化，程序的质量主要取决于软件设计的质量
但选用的程序语言的特点和编码风格会对程序的可靠性、可读性、可测试性和可维护性有深远影响
选择程序设计语言实用标准
系统用户的要求
可以使用的编译程序
可以得到的软件工具
工程规模
程序员的知识
软件的可移植性要求
软件的应用领域
编码风格遵循规则
规范化程序内部的文档
规范数据说明
规范语句构造
规范输入输出
最大化效率
11.2 软件测试
软件测试的两个阶段
单元测试
模块的编写者和测试者是同一人
综合测试
在结束单测后，由专门测试人员对软件系统进行综合测试
软件测试的目标
测试是为了发现程序中的错误而执行的程序的过程
好的测试方案是极可能发现至今尚未发现的错误测试
成功的测试是发现至今尚未发现的错误测试
软件测试准则和标准
所有测试都应该追溯到用户需求
应远在测试开始之前就制定出测试计划
把Pareto原理应用到软件测试中（测试发现的错误中80%可能是有20%的模块造成）
测试步骤
单元测试
模块测试
集成测试
子系统测试，把经过单测的模块放在一起形成子系统测试
系统测试
把经过测试的子系统装配成一个完整的系统测试
回归测试
重新执行已经做过的测试的某个子集
检测软件全部功能的代表性测试用例
专门针对可能受修改影响的软件功能做附加测试
针对被修改过的软件测试
确认测试
验收测试，验证软件功能和性能是否与用户要求一致
11.3 白盒测试技术
任何产品测试都有两种方法
黑盒测试
知道产品具有的功能，通过测试验证每个功能是否正常
白盒测试
知道产品内部程序结构和处理过程，通过测试验证执行过程是否正常
白盒测试使用的技术
逻辑覆盖
语句覆盖
判定覆盖
条件覆盖
控制结构测试
基本路径测试
在程序流程图基础上绘制程序图，通过分析由控制构造的环境复杂性，导出基本路径集合，设计测试用例保证这些路径至少通过一次
循环测试
简单循环
跳过循环
只通过循环一次
通过循环两次
通过循环m次，其中m<n-1 (n是允许通过循环最大次数)
通过循环n-1，n, n+1次
嵌套循环
从最内层循环开始测试，其它循环设置为最小值
对最内层循环使用简单的循环测试方法，而外层循环的迭代参数取最小值
由内向外，对下一个循环进行测试，保持其它外层循环最小值
继续进行下去，直到测试完成所有循环
串接循环
如果串接循环的各个循环都独立，则使用测试简单循环方法来测试，不独立时使用测试嵌套循环方法来测试
11.4 黑盒测试技术
黑盒测试与白盒测试是互补的测试方法，白盒在早期阶段进行，黑盒用于测试过程的后期
黑盒测试主要发现的错误：功能不正确或遗漏功能、界面错误、数据结构错误或数据库访问错误、性能错误、初始化和终止错误
设计黑盒测试应考虑的问题
怎样测试功能的有效性
哪些类型的输入可构成好的测试用例
系统是否对特定输入值特别敏感
怎样划定数据类的边界
系统能够承受什么样的数据率和数据量
数据的特定组合将对系统运行产生什么影响
黑盒测试使用的技术
等价类划分法
把程序的输入域划分若干个数据类，据此导出测试用例，一个理想的测试用例能独自发现一类错误
边界值分析法
选取刚好等于、稍小于和稍大于等价类边界值的数据为测试数据，避免发生程序错误
错误推测法
使用边界值分析法和等价类划分法有助于设计出容易暴露错误的测试方案，但不同类型不同特点的程序会有一些容易出错的情况；而错误推测法依靠直觉和经验进行，通过列出程序中有可能的错误和容易发生错误的特殊情况，根据它们选择测试方案
11.5 网络实现
主要是用通信线路把各种设备连接起来组成网络系统
工作内容
确定网络类型与结构
网络设备和服务器的选型与安装
网络拓扑结构
网络产品的选型
路由器设备、交换机设备
11.6 数据库实现
定义数据库结构
确定数据库的逻辑和物理结构后，通过选用DBMS提供的数据库定义语言（DDL）描述数据库结构钢
数据装载
数据库结构建立后，向数据库装载数据
数据入库步骤
筛选数据
转换数据格式
输入数据
校验数据
数据库试运行
应用功能测试、性能测试
11.7 系统转换
由旧系统向新的计算机信息系统过渡
系统转换策略
直接转换法
突然切入，在某一刻旧系统停止运行，新系统投入运行
并行转换法
新系统投入运行时，老系统并不停止运行，两系统同时运行一段时间
试点过渡法
位置转换，先选用新系统的某一部分功能替代老系统，作为试点逐步替换整个老系统
11.8 系统运行与支持
系统运行
信息系统的业务过程和应用程序周期性持续运行，管理员记录系统运行的正常情况和意外情况
系统支持与维护
对用户不间断的技术支持以及改正错误、遗漏或新需求
系统维护
程序的维护
数据文件的维护
代码的维护
系统恢复
恢复方式
从用户终端恢复程序
系统操作人员校正某些问题
系统崩溃在事务过程中，需要数据库管理员回滚恢复丢失的数据
由于网络问题发生的系统崩溃，需要网络管理员通过登录特定账号进行程序初始化恢复
技术支持
技术支持包括
例行监督系统的使用
主持用户满意度调查和会议
修正业务流程
提供额外培训
在资料库中记录改进想法
系统改进
系统运行期间，用户需求新增功能或对已有功能提出改进建议，从而需要对软件进行新增功能和修改已有功能
第12章 面向对象开发概述
12.1 面向对象相关概念
基本思想：客观世界由对象组成，任何事物都是对象；把所有对象划分成各种对象类，每个对象类定义一组数据和方法，类中数据表示静态属性，是对象的状态信息，类中方法表示对象动态属性，是允许施加在对象上的操作，类中方法是该类所有对象共享的
实体与对象
用户角度：对象既可以是具体的物理实体的抽象，也可以是人为的概念；软件开发角度：对象是一种将数据和处理这些数据操作合并在一起的程序单元
对象特点
以数据为中心
对象是主动的
实现了数据封装
本质上具有并行性
模块独立性好
类与对象
类是某些对象共同特征的表示，是创建对象的模版，对象是类的实例
消息
是要求某个对象执行类中所定义的某个操作的规格说明，消息由3部分组成：接受信息的对象，消息选择符，零个或多个参数
属性
是类中所定义的数据，是对客观世界实体所具有性质的抽象，类的每个实例都有自己的属性值
操作
是由类的所有实例提供的一个功能或服务
12.2 面向对象的操作
封装
是指对外界隐藏了对象的实现细节，使用对象只知道向外界提供的接口，无法知道内部的数据结构和实现操作的算法
继承
是指能够直接获得已有的特征和性质，而不必重复定义，面向对象中，继承是指子类自动共享基类中定义的数据和方法
多态性
在面向对象中，指的是子类对象可以像父类那样使用，同样的消息既可以发给父类对象，也可发给子类对象
12.3 面向对象开发的主要方法
Booch的OOD方法
以面向设计作为开发重点的代表性方法，整个开发工作分为微观和宏观过程
微观过程4个循环步骤
确定类和对象
确定对象和类的语义，建立对象和类的含义
确定类和对象之间的关系
实现类和对象，选择编程语言实现
宏观过程5个步骤
概念化、建立核心需求
分析和建立理想行为模型
设计并创建体系结构
细化并完善和实现模型
维护、管理并提交模型
Booch图技术特点
类图（类结构-静态视图）
对象图（对象结构-动态视图）
状态转移图（类结构-动态视图）
时态图（对象结构-动态视图）
模块图（模块体系结构）
进程图（进程体系结构）
Coad/Yourdon的OOA-OOD方法
CY方法严格区分了面向设计OOD和面向分析OOA，利用5个层次和活动定义记录系统行为
主题层
类和对象层
结构层
属性层
服务层
建立5层模型的基本步骤
确定类和对象，建立类和对象
确定继承与合成结构，建立结构层
将相似的类和对象归纳同一主题，建立主题词层
确定对象的属性，建立属性层
定义服务/方法，确定每个服务和消息连接，建立服务层
Rumbaugh的OMT方法
在实体-关系模型基础上扩展了类、继承和行为，是以分析为重点的代表性方法
从三个视角描述系统并建立模型
对象模型（信息结构图）
动态模型（状态转换图）
功能模型（数据流图）
开发过程的4个阶段
系统分析
问题描述采纳三模型
系统设计
对象设计
实现
Jacoson方法
1994年提出面向对象软件工程（OOSE）方法，以用例驱动为特点，涉及整个软件生命周期，包括：需求分析、设计、实现和测试 4个阶段
各种方法的集成
以上面向对象的开发方法都支持三种基本活动：识别对象和类、描述对着类之间的关系、通过描述每个类的功能定义对象的行为，只是侧重点不同
OOA-OOD
在信息模型化、面向对象的程序设计语言上建立的；主要工具：类与对象图、对象状态图、服务图
OOSE
有很强的行为能力，适合实时系统，其它方面较弱
OMT
通过三模型对系统进行描述，在分析方面较强，设计领域较弱
UML
融合了Booch、OMT和OOSE方法，1997年9月以UML1.1版本被批准成为面向对象开发的行业标准语言
第13章 UML
13.1 UML概述
UML的概念和特点
UML由OMG于1997年11月批准为标准的建模语言，基于Booch、OMT和OOSE三种面向对象方法基础建立，具有创建系统的静态结构和动态行为等多种结构模型的能力
需要注意的点
UML不是可视化程序设计语言，而是标准的图形化建模语言
不是工具或知识库的规格说明，而是建模语言规格说明
不是过程，也不是方法，但允许任何一种过程或者方法使用它
与具体实现无关，可应用任何语言平台和工具平台
与具体过程无关，可应用于任何软件开发过程
UML的构成
组成部分：视图、图、模型元素和通用机制
视图（View）
用来表示被建模系统的各个方面
模型元素
代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本概念
图
UML共定义了5类10种图
第一类 用例视图
第二类 逻辑视图（类图、对象图和包图）
第三类 行为图（活动图和状态图）
第四类 交互图（协作图和顺序图）
第五类 实现图（组件图和部署图）
通用机制
用于表示其它信息，比如注释模型元素的语义等
13.2 用例图
描述参与者和用例之间关系的图形，还可以将类似的用例放在一个包中，构成子系统
参与者
也称为角色，是系统外部的实体，以某种方式参与用例的执行过程（固定图形表示）
用例
是用户期望系统的具体动作，可以是一个行为相关的步骤序列，目的是完成一个单一的业务任务（椭圆表示）
关联
参与者和用例之间的关联关系（采用一条连接参与者和用例的实线表示）
用例之间关系
用例描述的是系统外部可见的行为，是系统为参与者提供的一段完整服务
13.3 类图和对象图
类图由（类名、属性、操作）三栏组成
类的定义
类的属性
是类的一个特性，描述了类的对象(实例) 所具有的特性值
类的操作
用于修改、检索类的属性或执行某些动作
类之间的关联
普通关联关系
常见的普通关联关系，表示符合是连接两个类之间的直线，通常关联是双向的，可在一个方向上为关联起一个名字，为避免混淆名字前后面加上一个表示方向的黑三角
聚合关联关系
组成聚合
是指部分与整体共存，整体不存在了部分也会随之小时（采用直线在整体端增加实心菱形表示）
共享聚合
表示类的对象之间的关系是整体与部分的关系（在表示关联关系的直线末端紧挨着整体类的地方画一个空心菱形）
泛化关联关系
泛化是指抽取事务的共性特征，形成超越特殊事物而具有普遍意义的一般事务的方法 （带有空心三角的实线符号指向超类，表示对子类泛化）
依赖关系
是两个模型元素之间语义上的连接关系，两个元素一个独立一个非独立（带箭头的虚线连接，指向独立的类）
精化关系
表示同一事务，建立在不同抽象层上的两种描述（用带有空心三角的虚线表示，空心三角指向需要细化的一端）
派生关联关系
派生属性是指可以从其它属性中推演得到的属性（年龄 可通过出生和当前日期推算得到，派生属性和派生关联名字前加斜杠 / 表示）
类的版型
也称为构造型，是UML3中扩展机制之一，另外两种扩展机制分别是：标记值和约束
对象图
是类图的一种实例化，一张对象图表示的是与其对应的类图的一个具体实例（对象名首字母小写，后面跟一个冒号，冒号后面是对象所属的类名，且整个名字带下划线）
对象图是类图的一种变形，除了在对象名下加下划线外，对象图使用的符号基本与类图相同
13.4 状态图
系统的动态建模主要描述系统的行为，包括：状态图、活动图、顺序图、协作图，其中状态和活动图描述系统的动态行为
状态
由圆角矩形表示，状态的改变称为转移，状态转移由箭头表示，箭头旁标记转移发生的条件
对象呈现的状态
初态：用实心圆表示
终态：用一对同心圆表示（内圆为实心圆）
中间状态：用圆角矩形表示
每个状态分为上中下3部分
上：名称
中：状态变量
下：活动表
事件
状态转换由事件触发，在表示状态转换的箭头线上标出触发转换的事件表达式
13.5 活动图
描述系统中各种活动的执行顺序，通常是描述一个操作中所要进行的各项活动执行流程
活动
活动状态用带有圆形边线的矩形表示，完成转换用箭头表示
泳道
顶部是对象或者域的名字，对应的矩形框包含活动
判定点
一个活动序列到达某个点，并在该点做出判定或者决策
并发路径
在对活动建模时，需要将一个转移划分分两个单独的并发执行的路径
对象流
表示活动和对象之间的关系，如一个活动创建对象或使用对象
信号
活动序列中的活动可以发送信号，发送信号用凸角五边形表示，接收信号用凹角五边形表示
13.6 顺序图
也叫时序图，描述了对象之间的动态交互关系，即消息是如何在对象之间发送和接收的
顺序图符号
顺序图是一组对象构成，每个对象分别带有一条竖虚线（对象生命线）代表时间轴，消息用水平箭头表示
对象
3种命名方式
第一种：表示对象名和类名
第二种：只显示类名不显示对象名（匿名对象）
第三种：只显示对象名不显示类名
消息
调用消息
异步消息
返回消息
阻止消息和超时消息
13.7 协作图
类图和顺序图的交集，协作图建模对象或角色，以及它们彼此的顺序
序列化
把消息按照执行的顺序排序
迭代
一种非常基本和重要的控制流类型，UML中迭代有两种标记符
控制点条件
根据消息的表达式的计算结果限制消息的发送
13.8 组件图
描述软件组件以及它们之间的依赖关系
组件
用一边有两个小矩形的长方形表示，用实线与代表组件接口的圆圈相连
依赖关系
使用在一端带有开放箭头的短划线表示
接口
组件接口两种表示法，第一种用矩形表示，矩形中包含接口有关的信息；第二种用一个小圆圈代表接口，用实线与组件连接
13.9 部署图
也叫配置图，描述系统中硬件和软件的物理配置情况及体系结构，是系统拓扑的物理描述
节点
指拥有某些计算机资源的物理对象，节点用立方体表示，两个立方体连接用一条线表示
通信关联
节点通过通信彼此关联，从一个节点到另一个节点绘制实线表示关联
13.10 包图
包是一种把类进行分组的方式，把分组后的元素用一个带有标签的文件夹围起来称为打包
包之间的关系
两个包之间的3中相关方法
一个包可以泛化另一个包
一个包可以依赖另一个包
一个包可以细化另一个包
合并包
一个包可以和别的包合并，合并是一种依赖关系，合并的结果是源包发生了变换
第14章 面向对象需求理解
14.1 基于UML的系统开发过程
面向对象的系统开发强调的是迭代开发和增量式开发，不要求一个阶段彻底完成
迭代开发生命周期：需求理解、分析、设计、构造、部署和实施
需求理解
了解业务过程，形成描述业务的 活动图
进行领域分析，了解客户领域中的主要实体，构造构造 高层类图
识别协作系统，建立部署图
发现系统需求，通过联合应用开发计划，细化类图
将结果提交给客户，得到认可后继续
系统分析
理解系统用户，进行高层用例分析
充实用例，分析每个用例中的步骤序列
细化类图，在类图中加入关联名、抽象类、多重性、泛化和聚集
分享对象状态变化
定义对象之间的交互
分析系统与其他协作系统的集成
系统设计
开发和细化对象图
开发构件图
制定部署计划
设计和开发用户界面原型
类的包化有助于进行系统结构设计
设计测试
编制文档
系统实现
编制代码
测试代码
构建用户界面和用户界面到代码的连接测试
完成文档
编制备份和恢复计划
在硬件上安装最终系统
测试安装后的系统
系统试运行
14.2 理解需求
理解需求并表达需求是成功进行开发的基础，用例建模是常用理解需求的方法
用例方法的特点
容易界定系统边界
将需求分析和设计分离
用例定义了系统功能的使用环境
根据用例来对目标系统进行测试
需求用例建模过程
确定业务参与者（系统的使用者）
参与者寻找
系统开发完成，会有哪些人使用
系统需要从哪些人或其它系统中获得数据
系统会为哪些人或系统提供数据
系统会与哪些其它系统相关联
系统是由谁来维护和管理的
确定用例
根据参与者来确定系统用例
参与者为什么要使用该系统
参与者是否会在系统中创建、修改、删除、访问、最复杂和最重要的用例
参与者是否会将外部的某些事件通知给该系统
系统是否会将内部某些事件通知该参与者
构建用例图
根据参与者和用例构造用例图，采用方框形式将系统边界勾画出来
用例说明
用例模型由用例图和每个用例详细描述用例说明组成，用例图使我们对系统有一个整体认知，可以知道有哪些参与者与系统发送交互
用例说明组成
用例说明要素
包含关系的用例说明
扩展关系的用例说明
泛化关系的用例说明
用例模型检查
从3方面对用例模型进行检查
需求完备性检查
用例模型的简洁和重要性检查
管理用例模型复杂度
第15章 面向对象分析
15.1 领域建模
面向对象分析的首要任务是建立问题领域的对象模型，从实际需求抽象出类，并描述各个类之间的关系
对象建模步骤
研究所要分析的问题领域，确定系统需求
发现对象和类，明确它们的含义，确定属性和操作
发现类之间的静态联系
设计类与联系
绘制对象类图并编制相应的说明
发现类
类模型是面向对象开发的基石，只有建立类模型，系统的状态和行为才能变成可观察的，但类是难以发现的，且类的属性不明显
4种识别类的方法
名词短语方法
通过在需求文档中查找名词短语的形式，将每个名词视作候选的类
通用类模式方法
从对象的一般分类理论中推演候选类
实体类
概念类
事件类
人员类
地点类
用例驱动方法
常用于UML建模，以用例描述进行补充，且每个用例采用协作图和顺序图来进行补充说明
CRC方法
常用于头脑风暴会议，具体使用需要准备特别的卡
混合方法
综合4种方法的优点
确定关联
分析确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未发现的类和对象
关联类的3种表现形式
普通关联
最弱的关联，表示两个类的对象之间有导航关系
聚合关联
包括组成聚合（强耦合）和共享聚合
泛化关联
利用继承机制共享公共性质
确定属性
属性是对象的性质，可以对类与对象和结果有更深入、更具体的认识
在属性确定时，常犯的6种错误
误把对象当属性
误把关联类的属性当作一般对象的属性
把限定误当成属性
误把内部状态当属性
过于细化
存在不一致的属性
15.2 行为建模
系统分析阶段的行为建模，主要是同步细化用例和对象类的过程，通过分析系统行为，印证和修正系统的静态结构，满足用户需求，达到系统目标
UML动态模型包括状态模型、顺序模型、协作模型和活动模型，通常用图形表示：
状态图
绘制状态图表现一个对象类的生命周期
建立步骤
确定状态机（类、子系统、整个系统）
选择初始状态和终结状态
发现对象的各种中间状态
确定状态可能发生的转移
找出触发状态的事件
绘制状态图
细化状态中的可选项（状态变量/活动表）
活动图
描述两个层面的活动，一个是用于描述用例场景，和描述对象交互
建立步骤
找出负责实现工作流的业务对象
确定工作的初始状态和终结状态，明确工作流边界
从工作流的初始状态开始，找出随时间而发生的活动和动作
对于复杂重复出现的一组动作，可以组成一个活动状态，用一个活动图来展示
给出连接活动和动作的转移
在活动图中给出与工作流有关的重要对象，用虚箭线把活动状态或动作状态连接
顺序图
描述用例中的交互活动，确定参与交互的对象和类，并确定相互之间的交互事件
建立步骤
找出参与交互的对象角色，横向排列在顶部，最重要的对象在左边，交互密切的对象相邻
对每一个对象设置一条垂直向下的生命线
从初始化交互的信息开始，自顶向下载对象的生命线之间安置信息
在生命线上绘出对象的激活期
根据消息之间的关系，确定循环结构及循环参数和出口条件
第16章 面向对象设计
16.1 系统设计与UML
面向对象分析（OOA）是提取和整理用户需求并建立问题域模型的过程；面向对象设计（OOD）是把分析阶段得到的需求转变成符合成本和质量要求，抽象的系统实现方案的过程
OOA和OOD的区别
OOA侧重于理解问题，描述软件做什么；OOD侧重于理解解决方案，描述软件如何做
OOA一般只考虑理想的设计，不关心技术和实现细节，OOD是更具体、更详细、更接近真实代码的设计方案
在设计结果描述方式上，分析阶段侧重秒速对象的行为，设计阶段侧重于描述对象的属性和方法
OOA只关注功能性需求，OOD既关注功能性需求，也关注非功能性需求
OOA产生的系统模型通常规模较小，OOD产生的系统规模较大，内容也比较完整
系统设计的主要任务
设计阶段要分析模型进行扩展并将模型进一步细化
定义真实用例
定义报告、用户界面
精化系统体系结构
定义交互图
定义设计类图
定义数据库模式
协作图
和顺序图一样，也是用来描述系统中对象之间的动态协助关系
绘制协作图步骤
找出参与交互的对象角色，作为图形节点放置协作图中，最重要的对象放在图中央，与它直接交互的对象放它附近
设置对象的初始性质
说明对象之间的关联
从初始化交互的消息开始，在链接上安置相应消息，并给出序号
处理循环、自调用、回调、多对象等特殊情况
组件图
组件是软件系统的一个物理单元，实现系统的源代码、二进制码可以安装模块化思想，用组件组织起来，明确系统各部分的功能职责
组件图绘制步骤
确定组件
对组件加上必要的构造型
确定组件之间的接口联系
必要时把组件组织成包
绘制组件图
部署图
又称实施模型，将应用程序的各部分在物理结构上进行安装和部署
绘制步骤
确定节点
对节点加上必要的构造型
确定联系
绘制部署图
16.2 通用职责分配软件模式（GRASP）
面向对象系统是由多个不同对象组成的，对象之间不仅存在关联还必须进行交互，问题是软件设计人员如何规定对象的消息
GRASP是能够帮助系统设计人员理解和实现有关类和对象的设计技术，描述了有关对象设计和职责分配的最基本指导原则
GRASP职责主要分2类
知道型职责
指一个对象需要了解一些消息，（知道自己私有的、封装的数据，知道与自己关联的对象信息、派生出来的事物）
做型职责
指一个对象完成某种动作行为或和其它对象协作完成某个动作行为（主要通过类中的方法实现）
GRASP的5个基本模式
专家模式
指在进行类职责设计时，如果发现某个类拥有完成该职责需要的信息，那这个职责就分配给这个类来实现
创建者模式
主要帮助设计人员确定创建对象的职责具体由哪个类来承担，避免不同模块都能对该类的对象进行实例化
控制器模式
主要指导设计人员将处理系统事件消息的职责分派给特定的类，该类接受需求消息并控制由哪个类对请求处理
低耦合模式
要求软件开发时，各组件、模块和类尽可能少地依赖其它的类，从而提高模块和组件的重用度（两个类存在控制、调用、数据传递关系则是耦合关系）
高内聚模式
使系统各模块之间尽可能充分合作，协调各个类职责之间的相关度和集中度，而不是由一个或几个包揽所有功能的超级类完成
16.3 类的设计
设计类
面向对象分析中重点是业务领域的实体类，面向对象设计期间引入接口类和控制类
实体类
对必须存储的信息和相关行为建模的类（持久存储体：数据库、文件等）
接口类
表示用户与系统接口的方式（窗口、对话框、报表、打印机接口等）
控制类
承载业务规则逻辑，控制其它类工作的类
设计关系
分析阶段类之间的关系（关联关系、聚合关系进和泛化关系）设计阶段类的关系（依赖关系、导航能力、属性与方法的可见性、对象责任）
依赖关系
描述两种情况下 类之间的关联关系
当一个变化出现在一个类中，它可能会影响另一个类
一个持久类和一个临时类之间的关系，接口类一般是临时的
导航能力
类之间的关联关系默认是双向的，一类对象导航(发送消息) 到另一类对象
属性与方法的可见性
可见性定义了属性和方法如何被其他对象访问
UML提供三层次可见性
公共可见性
可以被其他任何类的任何方法访问和调用
保护可见性
具有保护属性(方法)的类或子类可以访问调用改属性
私有可见性
私有属性(方法)只能被定义它的类访问
对象责任
对象封装了数据和行为，通过行为确定对象责任；对象责任是指对象手到请求时必须提供的服务
设计类图
系统开发设计阶段，设计人员需要确定系统各个类及类中的成员，还需要为系统中各个类添加方法，并定义对象之间的消息传递，最后产生设计类图
设计类图创建依赖两个模型（协作图、概念模型）设计类图内容（类、关联、属性，接口和操作，方法，属性类型信息，导航，类/接口元素之间依赖关系）
建立设计类图步骤
分析协作图，识别出所有参与软件解决方案的类，将其补充到初始类图中
分析协作图添加类图的方法，为属性和方法添加类型信息
在类图中添加关联，支持必要类的可见性
在关联上添加导航箭头，指明属性可见性的方向
添加依赖关系连线，指明非属性的可见性
16.4 接口设计
面向对像设计中，两个类不直接相连，由于接口和实现的分离，在程序编辑时可以不用考虑程序怎样编写，只需考虑对象交互的接口
单个对象的接口设计
通常是封装某种算法的对象，如业务规则计算对象或业务逻辑处理对象
多个对象接口设计
将系统中对象相同的行为方法提前出来形成接口，然后所有对象都实现这个接口
层次之间的设计
系统应用架构各层之间交互复杂，应用分层目的是各司其职，如果没有良好的接口设计，各层之间交互会比较混乱
16.5 包设计
包是在物理上组织和管理文件的包装器，作用是将类文件有序放置在一起
包设计原则
自顶向下原则
分包时要像组织机构一样，自顶向下延伸，下层不能够访问上层包，但层次之间的包可以相互访问
职责集中原则
尽量将一组业务功能相关的类分在同一包中
互不交叉原则
指包与包之间尽量独立，少产生依赖关系
包设计步骤
设计软件层次包
软件建立时基本确定，应用自顶向下原则，命名规则为：组织类型+项目名称+具体内容
设计软件模块包
采用用例驱动开发模式，软件模块依据用例划分，这个过程形成以用例为基础的软件模块包，应用职责集中原则
设计软件代码包
将类归纳到相应模块包，并考虑实际类之间的依赖关系，应用互不交叉原则
16.6 数据库设计
应用程序都需要一个持久化的存储（关系数据库）存放和读取信息，对象数据库通过接口与数据库交互；关系数据库由于面向记录与面向对象数据表示之间存在不匹配，则需要特殊的对象服务，UML通过类图描述了系统中各种类和对象之间的静态结构，关系数据库中类与表相对应
UML类图映射为库表的原则
类图之间的关系细分为普通关联、泛化关联、聚合关联
类和属性的实现
将类之间或间接映射成表
将类的属性映射成字段
将类图中的属性类型映射成表的域
关联的实现
关系数据库中，可通过外键实现类的关联，外键允许表中的某一行与其他表中的行为相关联
泛化的实现
将整个类层次映射为单个数据库表，即基类和子类共建一张表
每个具体子类映射成单个数据库表
每个类均映射为数据表
聚合的实现
聚合与组合关系的映射规则与二元关系相似
递归关联
类图中的递归关联在映射为数据库时，将类图转换为一张库表，在表中添加父类
关系约束检查策略
UML中，类之间的关系反映具体的商业规则，因此将类映射到关系数据库时，必须保证类之间关系的正确定义，确保在数据库实施中对数据的约束
第17章 面向对象实现
17.1 设计映射到代码
设计阶段产生的UML设计类图和协作图将作为代码产生阶段的输入，UML不是程序设计语言不能直接书写程序，因此UML建立的模型须转换为某个程序设计语言的源代码程序，然后经过该语言编译生成可执行的软件系统
根据设计类图创建类的定义
设计类图中至少应该描述：类名、超类、方法特征标记和简单的类属性
根据协助图创建方法
协作图显示相应方法调用产生的消息传递，这些消息序列可以被翻译成方法定义中的一系列语句
17.2 面向对象程序设计
程序设计遵循的准则
可重用原则
提高方法的内聚性（一个方法只完成单个功能）
减小方法的规模
保持方法的一致性
把策略与实现分开
可扩充原则
封装实现策略
不要用一个方法遍历多条关联链
避免使用多分支语句
精心确定公有方法（面向用户接口）
健壮性原则
预防用户的操作失误
检查参数的合法性
不要预先确定限制条件
先测试后优化
17.3 面向对象测试策略
传统软件测试是从输入-处理-输出的角度检验函数或过程能否工作；面向对象程序中对象是属性和方法的封装体，相互协作又彼此独立
面向对象软件测试的三个层次
面向对象测试过程以增量方式进行；首先对单个类进行测试，然后将多个类集成的子系统或类簇进行集成测试，最后将类簇或子系统集成最终的系统后进行系统测试
单元测试
软件开发中，单元的概念发生了变化，是以封装的类或对象作为最小的可测试单位
集成测试
贯穿软件构造的过程，是对类之间的协助进行测试，常见的测试方法：基于场景测试、行为测试
系统测试
面向对象集成测试的最后测试阶段，主要以用户需求为测试标准，需要参考面向对象分析和分析测试的结果
回归测试
不再作为测试的一个独立阶段，而是以增量方法进行，采用层次增量的测试模型，对单个对象方法的集成测试中，确定对哪些测试用例进行回归测试
设计测试用例
面向对象开发采用用例驱动的开发模式
用例测试步骤
确定测试用例场景
是推导测试用例的出发点，已经在系统分析过程中明确，无需重新开发
确定测试执行路径
测试用例目标是覆盖用例中提到的各种场景，因此需要把所有可能场景罗列形成场景集合（主事件流和备选事件流的排列组合结果）
设计并执行测试用例
根据所设计的测试用例，在符合用例输入数据的范围要求内输入相应数据，并给出预期结果
收藏
0 条评论
下一页
