基于UML的学生顶岗实习管理系统分析与设计(投电脑知识与技术定稿)

第一篇：基于UML的学生顶岗实习管理系统分析与设计(投电脑知识与技术定稿)

基于UML的学生顶岗实习管理系统分析与设计

马先波

（日照职业技术学院，山东 日照 276826）

摘要：顶岗实习是高职院校重要的实践教学环节，要实现对顶岗实习的有效管理，需要借助网络技术搭建管理平台，实现对参与实习师生的管理与指导。该文在对顶岗实习流程及实习任务分析基础上，运用UML建模方法对系统进行分析建模与设计建模，并提出了系统框架与解决方案。

关键词:顶岗实习;UML;建模;系统分析;系统设计;管理系统

中图分类号：TP31

5Analysis and Design of The Students Internship

Management System Based on UML

MA Xian-bo

(Rizhao Polytechnic, Rizhao, 276826, China)

Abstract: Internship is important practical teaching in Higher Vocational Colleges, the Internship in order to achieve effective management of the need to build management platform with network technology to realize the management of teachers and students involved in internships and guidance.Internship in the paper in the process and practical tasks based on the analysis, the use of UML modeling method to analyze the system modeling and design modeling, and the system framework and solutions.Key words：Internship;uml;modeling;Systems Analysis;Systems design

1引 言

顶岗实习是高职院校在探索工学结合、校企合作办学模式中重要的实践教学环节，在培养高技能人才过程中具有非常重要的作用，是完善“职场体验→实境训练→顶岗历练”人才培养模式的重要举措。顶岗实习期间学生作为学生同时又是企业员工，接受学校和企业的双重管理，学生实习比较分散而且远离学校，教师不能与实习学生直接交流，学生在心理、工作、人际关系处理、毕业设计、毕业论文等方面产生的问题教师不能及时帮助解决，甚至存在与企业的沟通协调不够，管理不到位、实习生放任自流的现象。顶岗实习管理系统的开发和运用可有效解决以上问题，补充完善顶岗实习管理体系，有效提高顶岗实习管理效率和水平。

2系统需求分析与建模

软件系统的需求分析，通过深入描述顶岗实习目标系统的功能和性能，定义软件的功能和性能需求。顶岗实习管理系统的开发，以实习学生、指导教师、企业为核心，以实习工作流程和实习任务为内容，采用基于UML的面向对象的方法进行建模。

顶岗实习系统的使用者有系统管理员、院部管理员、企业管理员、学校实习指导教师、企业实习指导教师、学生等六个用户，系统能够实现对参加实习的学生、指导教师、合作企业进行管理，并可以实现实习指导教师的分配、实习岗位的分配等内容。系统实现顶岗实习的日常管理，主要包括学生提交顶岗实习申请、填写实习工作计划日程表、填写实习日志、提交实习总结报告、师生交流论坛等，并可以实现指导教师和学生的相互评价。系统另一主要功能是实现对毕业设计和毕业实习的管理，主要包括提交毕业设计和毕业论文题目、填写毕业设计和毕业论文计划、提交毕业论文

并组织答辩，并能够和指导教师实现及时信息交互。实习学生可以通过系统提交毕业论文答辩申请，并提交毕业设计和毕业论文，指导教师审核通过后，组织答辩并录入答辩记录和答辩成绩。企业指导教师可以进行实习岗位分配、实习测评管理、意见反馈，并填写实习指导记录。院部管理员可以通过系统进行实习情况统计，对申请实习的学生安排实习指导教师和实习企业，统计实习测评情况、统计论文答辩情况、分析实习成绩和论文成绩等，指导教师可以对所指导的学生进行实习情况统计、统计论文答辩情况和成绩报送等。系统还要实现对用户的管理、权限设置、工作流程设置等。

对系统需求分析归纳总结，识别参与者并以参与者的角度归纳系统需求特性。对需求特性进行合并归纳，得到系统用例模型如图1所示。用例模型的描述需要进

提交毕业论文题目和计划

实习教师/岗位分配合作企业管理

论文答辩统计

制定实习计划

图1 系统用例图

一步对每一个用例进行详细的用例规约描

述，包括用例名称、前置条件、后置条件、基本事件流、扩展事件流等，并形成文档。

3系统设计与建模

系统设计的目的是建立一个完整的解决方案，并能够比较容易地转换成代码。本系统采用MVC架构下的三层结构体系，对分析阶段的模型进行细化，并且定义除实体类之外的边界类和控制类，共同构建系统模型。

在系统分析建模中，重点分析了与问题描述域和系统功能相关的对象，在系统设计过程中把系统的类对象分为实习管理和毕业设计管理两大类，利用动名词的方法发现类，然后决定候选类，并分析得到系统类如下：学生类（I_Student）、实习指导教师类（I_Teacher）、实习计划（I_Plan）、实习日志（I_Log）、实习报告(I_Report)、实习指导记录(I_ GuidingRecords)、实习情况表(I_T_S_List)、实习岗位（I_ Post）、实习成绩（I_Score）、毕业设计(G_Design)、毕业论文(G_ Paper)、毕业论文成绩（G_Score）等。

这些类之间我们可以用关联关系作简要表达，对每个类的职责进行简要的分析得到系统类图如图2所示。在图中每条有直接多重性关联的线上已标示出多重性，这为以后编程中提供了更好的关联参考价值，并为

类在整个开发中的统一性奠定基础。图2 系统类图

在完成系统对象和对性之间的静态结

构后，下一步重点描述系统对象及其关系的变化情况，这些情况可以使用UML的动态模型中的交互图进行描述。在系统的动态建模过程中，系统中对象之间通过消息机制来进行交互，交互图是指实现某个目标，而在一组对象之间进行交互的一组消息所表示的行为。交互图可以应用在分析模型和设计模型中，在分析模型中交互图侧重于分析类的职责分配和交互路程，而设计模型中交互图侧重

于设计类的引入和实际方法的调用与流程控制。系统以指导教师评价学生实习情况为例进行交互图建模，首先确定交互的对象有指导教师、登录页面、实习日志、实习报告、成绩录入存储等，然后确定各对象之间的消息交互流程，并可选择性地利用交互片段、迭代及监护条件等来表示循环和分支，建立起系统动态视图，如图3所示。

:

4基于B/S模式的系统结构

在完成顶岗实习系统的分析与设计后，基本上形成了系统的逻辑数据处理流程，系统总体上对数据进行获取、处理及存储操作，需要按照三层体系结构进行架构，分为浏览器层、逻辑处理层、数据管理层。系统开发建议采用基于JAVA的面向对象技术，底层数据管理采用安全性较好、稳定的MS SQL数据库管理系统，通过JAVABEAN对象组件完成对后台数据库服务的访问。

基于UML的顶岗实习系统的开发过程，对

图3 指导教师实习评价顺序图

系统的实用性、先进性和可复用性都有很大的提高，使系统具有良好的可靠性、可维护性和扩展性，对规范顶岗实习管理，提高管理水平和效率具有重要的意义。

[1] 张美忠, 谢洪.高职学生顶岗实习的探索与实践[J] ,北京:职业与教育,2009.164-165.[2] 俞校明, 张红.高职生顶岗实习过程设计与质量控制研究[J], 吉林:职业技术教育，2009.66-67.[3] 徐峰, 陈喧.UML面向对象建模基础[M], 北京:中国水利水电出版社，2006.

第二篇：UML食堂售饭系统分析与设计

食堂售饭系统分析与设计

目录

1.需求分析与描述.............................................................................1 1.1 需求分析.................................................................................1 1.2 用例分析.................................................................................1 1.3 用例模型图.............................................................................3 1.4 用例事件流描述.....................................................................4 2.领域模型分析...................................................................................7 3.工作流程分析...................................................................................8

食堂售饭系统分析与设计

1.需求分析与描述

1.1 需求分析

 持卡人：办理新饭卡，给饭卡充值，注销饭卡，挂失/撤销挂失饭卡，补办新卡，退还饭卡，使用饭卡消费，查看个人消费的明细。 管理部门：通过计算机系统具体实现持卡人需求中的项目。

 食堂工作人员：通过自动售饭机输入饭菜的金额，通过计算机系统对当天的营业情况进行汇总统计。

1.2 用例分析

1)系统的边界

对于系统边界，系统首先会包含需求分析中所需要软件实现的各项功能，此外还须确定食堂售饭系统是否包括管理部门和食堂工作人员。

就食堂售饭系统而言，其主要功能是让用户（即持卡人）享受服务（即用饭卡使购买饭菜的过程绕过了付款及找零的环节，提高了服务效率），而管理部门和食堂工作人员的作用都是为了使用户免于对系统的直接操作而设置的，因而此两者应归为食堂售饭系统的内部，相当于用户和具体的计算机软硬件系统之间的接口。

2)系统的执行者

持卡人需要通过食堂售饭系统来使用其所持有饭卡买饭，因而是整个系统的执行者；

管理部门根据持卡人的需求操作计算机系统从而实现与饭卡相关信息的管理，相当于其中饭卡信息管理子系统的使用者，是位于食堂售饭系统内部的执行者；

食堂工作人员同样通过操作计算机系统来实现购买饭菜过程中的扣费

食堂售饭系统分析与设计

功能以及对营业情况进行的汇总统计的功能，相当于其中消费处理与统计子系统的使用者，也是位于食堂售饭系统内部的执行者。

这样得到了系统中的执行者：  持卡人  管理部门  食堂工作人员

3)系统的用例

根据用户需求及执行者的分析，得到系统的用例如下：  办理新饭卡  饭卡充值  注销饭卡

 挂失/撤销挂失饭卡  补办饭卡  退还饭卡

 查看个人消费的明细

 扣除饭卡费用（对应于持卡人使用饭卡消费） 汇总统计

食堂售饭系统分析与设计

1.3 用例模型图

根据前面的分析，可以得到系统的用例模型图，如上图所示。对其中3个执行者和8个用例的简单描述如下：

执行者：

 持卡人：饭卡的持有者，通过食堂工作人员的操作直接使用饭卡进行消费，并通过管理部门对其饭卡进行管理。

 管理部门：负责根据持卡人的需求操作计算机系统，从而实现办新卡、充值、注销、挂失/撤销挂失，补卡、退卡、查看消费明细等功能。 食堂工作人员：负责根据饭菜的金额操作自动售饭机实现扣费功能，没隔一段时间对营业情况进行汇总统计并打印出相关文档。

食堂售饭系统分析与设计

用例：

 办理新饭卡：管理部门人员负责在用户申请新卡时替用户办理新饭卡。 饭卡充值：管理部门人员负责根据持卡人所给的金额向饭卡中追加存款金额。

 注销饭卡：管理部门人员负责在持卡人补办新卡或退卡时注销其原有饭卡。

 挂失/撤销挂失饭卡：管理部门人员负责在持卡人因饭卡遗失申请挂失时进行挂失饭卡操作，在其找回饭卡时撤销对饭卡的挂失。

 补办饭卡：管理部门人员负责在持卡人确认饭卡丢失或者损坏时替其补办饭卡，更改饭卡版本号，并实现只能使用最新版本号的饭卡。 退还饭卡：管理部门人员负责在持卡人申请退卡时清除卡内信息，退还剩余金额和押金。

 查看个人消费的明细：管理部门人员负责在持卡人申请查看其消费明细时执行次操作。

 扣除饭卡费用：食堂工作人员负责在持卡人持卡消费时根据饭菜的价格对饭卡进行扣费操作。

 汇总统计：食堂工作人员负责在每天营业结束后对营业情况进行汇总统计并打印相关报表。

1.4 用例事件流描述

1.办理新饭卡

 基本流

1.用户申请办理新饭卡

2.管理部门收取其押金和存款，记录持卡人相关信息 3.管理部门创建新饭卡的相关信息 4.用户领取新饭卡  备选流

无

食堂售饭系统分析与设计

2.饭卡充值

 基本流

1.持卡人申请对饭卡充值 2.管理部门向持卡人收取现金

3.管理部门根据持卡人要求向饭卡中充值  备选流

3.a 如果收取现金金额大于充值额度，管理部门向持卡人找零

3.注销饭卡

 基本流

1.持卡人申请注销饭卡 2.管理部门注销饭卡  备选流

无

4.挂失/撤销挂失饭卡

 基本流

1.持卡人申请挂失/撤销挂失饭卡 2.管理部门执行相应操作  备选流

无

5.补办新卡

 基本流

1.持卡人申请补办新卡

2.管理部门注销持卡人原有饭卡，读出余额，清除卡内信息 3.管理部门创建新饭卡的相关信息 4.管理部门更新持卡人的相关信息

食堂售饭系统分析与设计

5.持卡人领取新饭卡  备选流

无

6.退还饭卡

 基本流

1.持卡人申请退还饭卡 2.管理部门收回饭卡

3.管理部门将押金退还持卡人并清除卡内信息  备选流

2.a 如果卡内有剩余金额，管理部门想持卡人退还相应金额

7.查看个人消费的明细

 基本流

1.持卡人申请查看个人消费的明细 2.管理部门让持卡人输入饭卡密码 3.持卡人查看其消费的明细  备选流

2.a 如果饭卡密码错误，给出提示，结束

8.扣除饭卡费用（对应于持卡人使用饭卡消费）

 基本流

1.持卡人购买饭菜，将饭卡放到自动售饭机上 2.食堂工作人员在自动售饭机上输入饭菜的金额 3.自动售饭机查询饭卡余额 4.卡内金额扣除  备选流

3.a 如果卡中金额不够用，给出提示，结束 4.a 如果卡内金额低于底线，给出提示，结束

食堂售饭系统分析与设计

9.汇总统计

 基本流

1.食堂工作人员按需求对营业情况进行汇总统计 2.打印相关报表  备选流

无

2.领域模型分析

食堂售饭系统分析与设计

3.工作流程分析

办理新卡

饭卡充值

食堂售饭系统分析与设计

挂失/撤销挂失饭卡

补办饭卡

食堂售饭系统分析与设计

查看个人信息明细

注销饭卡

食堂售饭系统分析与设计

退还饭卡

扣除金额

食堂售饭系统分析与设计

汇总统计

第三篇：软件系统分析与设计

第1章

软件工程基础知识 1.1软件工程知识体系

 软件需求（Software Requirements） 软件设计（Software Design）

 软件构造（Software Construction） 软件测试（Software Testing） 软件维护（Software Maintenance）

 软件配置管理（Software Configuration Management） 软件工程管理（Software Engineering Management） 软件工程过程（Software Engineering Process）

 软件工程工具和方法（Software Engineering Tools and Methods） 软件质量（Software Quality）

1.2软件生存周期与软件开发模型

 1.2.1 软件生存周期

 Boehm定义的软件生存周期模型

 GB 8566-1988定义的软件生存周期模型

 GB/T 8566-1995定义的软件生存周期过程模型  GB/T 8566-2001定义的软件生存周期过程模型  UP定义的软件生存周期模型

 1.2.2 软件开发模型

 瀑布模型（waterfall model）

 快速原型模型（rapid prototype model） 演化模型（evolutionary model） 增量模型（incremental model） 螺旋模型（spiral model）

 喷泉模型（water fountain model）

1.3软件质量模型与软件质量管理

 1.3.1 软件质量模型

 软件产品的内部质量、外部质量和使用质量  质量特性、质量子特性和度量

 功能性：适宜性、准确性、互用性、依从性、安全性  可靠性：成熟性、容错性、可恢复性  可用性：可理解性、易学性、可操作性  效率：时间特性、资源特性

 可维护性：可分析性、可修改性、稳定性、可测试性  可移植性：适应性、易安装性、一致性、可替换性

 1.3.2 软件质量管理

 质量需求分析  质量计划  质量保证  质量控制  质量改进

 软件质量管理体系

         

 

            

  

1.4软件配置管理

 1.4.1 软件配置项与基线

计算机软件配置项（CSCI）基线（baseline）

功能基线（functional baseline）指派基线（allocated baseline）产品基线（product baseline）

 1.4.2 软件配置管理过程

对象标识 版本控制 变化控制 配置审计 配置报告

1.5软件过程管理

 1.5.1 软件能力成熟度模型（CMM）

CMM的5个等级：初始级、可重复级、已定义级、已管理级、优化级 CMM的关键过程域（KPA）：需求管理、软件项目计划、软件项目跟踪和监控、软件子合同管理、软件质量保证、软件配置管理、组织级过程焦点、组织级过程定义、培训大纲、集成软件管理、软件产品工程、组间协调、同行评审、定量过程管理、软件质量管理、缺陷预防、技术变更管理、过程变更管理

 1.5.2 软件过程与软件能力成熟度评估

第一步，建立评估组 第二步，填写提问单 第三步，响应分析 第四步，现场考察

第五步，提出调查发现清单

第六步，制作关键过程域（KPA）剖面图

 1.5.3 软件过程改进

第一步，比较“目标状态”与“目前状态”，找出所有差距 第二步，确定改进目标 第三步，制定改进计划 第四步，执行改进计划

第五步，总结本轮改进经验，开始下一轮改进

1.6

小节

软件工程学是研究如何有效地组织和管理软件开发的工程学科。

软件产品所要经历的计划、分析、设计、编程、测试、维护直至被淘汰这样一个全过程被称为软件生存周期。用不同的方式将软件生命周期中的所有开发活动组织起来，可以形成不同的软件开发模型。

软件质量就是软件与明确地和隐含地定义的需求相一致的程度。软件质量管理是指软件开发机构为保证软件项目满足客户需求所要实施的质量活动。软件配置管理是在软件的整个生命期内管理变化的一组活动，目标是使变化更正确且更容易被适应。

软件过程是指人们用于开发和维护软件及其相关产品的一系列活动，包括软件工程过程和软件管理过程。软件过程管理的目的就是提升软件组织的提高软件开发能力。

 1. 1.    

                       

第2章

项目管理基础知识 2.1项目与项目管理  2.1.1 项目

项目是在特定条件下、具有特定目标的一次性任务，是在一定时间内、满足一系列特定目标的多项相关工作的总和。项目的临时性 项目的独特性 项目的渐进性

2.1.2 项目管理

项目管理就是将各种知识、技能、工具和技术应用于项目之中，以达到项目的要求。项目范围 项目时间 项目成本 项目质量

2.2项目管理过程与过程组  2.2.1 过程与过程组

过程就是一组为了完成一系列事先指定的产品、服务或成果而需执行的互相联系的行动和活动。软件项目管理过程可归纳为五个过程组。启动过程组（initiating process group）规划过程组（planning process group）实施过程组（executing process group）

监控过程组（monitoring and controlling process group）收尾过程组（closing process group）

 2.2.2 项目管理过程的交互作用

项目管理过程并不是互不相干的一次性事件

项目管理过程组之间是一种前后衔接、承前启后的关系

项目管理过程组之间有时又是一种时间交错、空间并行的关系 项目管理过程组之间还是一种信息收集、存储、处理和传递的关系 某些过程组的关联具有重复迭代性

规划过程组、执行过程组和监控过程组之间形成一种闭环的关系 过程组的交互作用往往还会跨越项目阶段 项目阶段和过程之间有相互联系

 2.2.3 项目管理过程的裁剪

不同类型的软件项目应选用不同的项目管理过程 不同阶段的软件项目应选用不同的项目管理过程 不同软件项目的管理过程会有不同的具体过程 不同软件项目的管理过程会有不同的具体过程顺序 不同软件项目的管理过程会有不同的条件与约束 不同软件项目的管理过程会有不同的简化程度 不同软件项目的管理过程需要不同的集成程度 项目变更会使项目管理过程随之变化

2.3项目管理知识体系

项目综合管理 项目范围管理

          项目时间管理 项目成本管理 项目质量管理 项目人力资源管理 项目沟通管理 项目风险管理 项目采购管理

2.4小节

项目管理就是将项目管理知识、技能、工具和技术应用于项目活动之中，可以将软件项目管理活动视做一系列相互联系的过程。

项目管理过程可归纳为5个过程组：启动过程组、规划过程组、实施过程组、监控过程组与收尾过程组。

项目管理包括9个知识领域：项目综合管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理与项目采购管理。

第3章

软件开发技术 3.1软件开发平台

 3.1.1 Microsoft.NET平台

Microsoft.NET Framework：.NET CLR（通用语言运行环境）；.NET BCL（基础类库）；ASP.NET；ADO.NET。

Microsoft Visual Studio.NET：ADO.NET组件；XML数据组件；Windows表单组件；ASP.NET应用服务；ASP.NET Web表单；Web服务支持。

 3.1.2 J2EE平台

组件-容器：搭建体系架构平台标准服务 多层应用模型

3.1.3 Microsoft.NET与J2EE的异同

类似的平台基础构造 相同的三层/多层体系 不同的移植、性能和扩展 在Web支持方面的比较 第三方厂商的支持 潜在的市场

3.2中间件技术  3.2.1 中间件简介

终端仿真/屏幕转换中间件 数据访问中间件 远程过程调用中间件 消息中间件 交易中间件 对象中间件

Web服务器中间件 安全中间件

 3.2.2 消息代理中间件  

     1.  1.       

        

              



 构件化的结构

可恢复性、易于管理、灵活性 具有数据转换设施。可靠高效的通信 多样的管理能力 丰富的应用开发环境

 3.2.3 面向数据库的中间件

ODBC JDBC 数据库网关

3.3构件技术  3.3.1 构件库

构件的存储

构件的分类与检索机制 构件库的编目

构件库的管理和维护

 3.3.2 构件模型

3C模型

刻面（Facet）模型 青鸟模型

 3.3.3 构件的属性与特点

构件是可独立配置的单元，构件必须自包容。

构件强调与环境和其他构件的分离，因此构件的实现是严格封装的，外界没机会或没必要知道构件内部的实现细节。

构件可以在适当的环境中被复合使用，因此构件需要提供清楚的接口规范，可以与环境交互。

构件没有个体特有的属性，最多仅有特定构件的一份副本。

 3.3.4 构件与中间件

中间件，本质上是对分布式应用的抽象，中间件与系统架构实际上是从两种不同的角度看待软件的中间层次。

中间件促进了构件化软件，基于中间件开发的应用系统是构件化的，中间件提供了构件的体系结构，极大提高了构件化软件开发的效率和质量。构件化的软件设计思想在中间件发展中起到了重要的作用。

3.4小节

Microsoft.NET平台和J2EE平台是目前最常用的两大软件开发平台。作为彼此竞争的应用平台，Microsoft.NET平台和J2EE平台在目标和体系结构上极其相似，但在实现上又完全不同。二者总的关系是：异中有同，同中有异。中间件是处于操作系统和应用程序之间的软件。中间件保持了平台的透明性，抽象了典型的应用模式。应用软件开发者可以基于标准的中间件进行再开发，而不必再考虑操作系统的问题。

构件是可复用的软件成份，可被用来构造其他软件。中间件促进了构件化软件，应用系统在中间件提供的环境中可以更好地集中于业务逻辑上，并以构件的形式存在。构件思想也反过来推动了中间件的发展。

第4章

软件项目规划

4.1项目策划

 1. 1.从政策导向中寻找项目机会 从市场需求中寻找项目机会 从技术发展中寻找项目机会 从特定事件中寻找项目机会

4.2项目可行性分析 4.2.1 技术可行性分析

     1.         项目的必要性分析

软件组织水平与能力分析 项目技术来源分析 与项目相关的专利分析

项目负责人及技术骨干的资质分析 项目总体技术方案分析 项目创新点分析 项目技术风险分析 项目技术成熟性分析

 4.2.2 项目投资及效益分析

项目投资预算分析 项目投资来源分析

市场需求与产品销售额分析

产品成本、利润与盈亏平衡点分析 投资回收期、投资收益率分析 社会效益分析

4.3项目论证、评估与立项

 4.3.1 项目论证与评估的基本概念

项目论证是指对拟实施项目技术上的先进性、成熟性、适用性，经济上的合理性、盈利性，实施上的可能性、风险性进行全面科学的综合分析，为项目决策提供客观依据的一种技术经济研究活动。

项目评估指在项目可行性研究的基础上，项目投资者或项目主管部门或其委托的第三方权威机构根据国家颁布的政策、法律、法规、标准和技术规范，对拟开发项目的市场需求、技术先进性和成熟性、预期经济效益和社会效益等进行评价、分析和论证，进而判断其是否可行的过程。

项目论证与评估的内容、程序和依据大同小异，只是侧重点稍有不同，有时不加区分或合并进行。

 4.3.2 项目可行性报告的真实性评估

项目申请单位的资质真实性评估 项目申请单位的财务真实性评估 项目申请单位的技术真实性评估 其他事项的真实性评估

 4.3.3 项目可行性报告的客观性评估

技术创新点的客观性评估

技术先进性与成熟性的客观性评估 





     

    信息安全措施的客观性评估

采用标准、规范的先进性、合理性评估 项目风险及应对方案的客观性评估 其他事项的客观性评估

 4.3.4 评估报告

 项目概况  评估目标  评估依据  评估内容

 评估机构与评估专家  评估过程

 详细评估意见

 存在或遗漏的重大问题  潜在的风险  评估结论

 进一步的建议

 4.3.5 项目立项

项目立项的决定应当由项目团队之外的、适当级别的、并为项目出资的项目发起人或投资人作出，通常以项目立项决定（通知）书、项目批文、项目许可证书和项目任务书等形式发布。

4.4项目开发计划

 1．引言  2．引用文件  3．项目最终成果  4．需求与约束

 5．系统开发总体计划  6．项目开发详细计划  7．进度表与活动网络图  8．项目组织与资源  9．培训

 10．项目估算  11．风险管理  12．支持条件  13．注解  14．附录

4.5小节

 软件项目规划的任务主要包括项目策划、可行性研究、论证、评估、立项与项目开发计划的制订工作。

 项目策划，也称项目机会研究，其目的是选择投资机会、鉴别投资方向。

 项目可行性分析的目的是确定以下问题：项目有无必要？能否完成？是否值得去做？  项目论证与评估的目的是审查项目可行性研究的可靠性、真实性和客观性，为项目主管部门或投资机构的立项决策提供科学依据。

 项目开发计划是项目规划阶段的重要成果，编写软件项目开发计划时可依据《GB/T 8567-2006 计算机软件文档编制规范》中的软件开发计划模版。

 

    









        

第5章

系统分析方法学 5.1系统需求分析与软件需求

系统需求：系统总体功能和业务结构；硬件系统需求；软件系统需求；硬件系统和软件系统之间的接口需求。软件需求：软件能力需求；软件外部接口需求；软件内部接口需求；软件内部数据需求；适应性需求；安全性需求；保密性和私密性需求；软件环境需求；计算机资源需求；软件质量需求；设计和实现的约束；数据需求；操作需求；故障处理需求；算法需求；相关人员需求；相关培训需求；相关后勤需求；包装需求；其他需求。

5.2结构化分析

结构化分析（SA）方法是一种面向数据流的需求分析方法，基本思想是自顶向下逐层分解。

数据流图（DFD）和数据字典（DD）是结构化分析最常用的工具。数据流图用来描述数据流从输入到输出的变换流程。

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。

数据流图和数据字典共同构成系统的逻辑模型。

5.3原型化方法

 5.3.1 原型化方法与结构化方法的比较

结构化方法的假设：所有的需求都能被预先定义；修改定义不完备的系统代价昂贵且实施困难；项目参加者之间能够清晰进行准确的通信；静态描述或图形模型对应用系统的反映是充分的；结构化方法的生命周期的各阶段都是固有正确的。

原型化方法的假设：并非所有的需求在系统开发以前都能准确地说明；有快速的系统建造工具；项目参加者之间通常都存在通信上的障碍；需要实际的、可供用户参与的系统模型；需求一旦确定，就可以遵从严格的方法；大量的反复是不可避免的、必要的，应该加以鼓励。

 5.3.2 原型生命周期及其策略

原型生命周期划分：选择开发方法；识别基本需求；开发工作模型；模型验证；修正和改进；判定原型完成；差别细部说明；严格说明细部；判定原型效果；整理原型和提供文档。

原型化的策略：建立数据模型；利用组合工程；剪裁和粘贴；用系统举例；字典驱动；文档的自动化；小的原型化队伍；交互式开发平台；陈述性规格说明；终端用户报表生成器；专业原型化人员；开发人员参加原型化。

5.4面向对象的分析

 5.4.1 面向对象方法学概述

对象与封装 类

继承与多态性 消息通信

面向对象方法学的优点

 5.4.2 面向对象的分析方法

OMT方法简介 建立对象模型 建立动态模型 建立功能模型





  

       1.  1.    

     

5.5小节

系统分析涉及系统需求的获取、分析、规格说明和确认。系统需求可分为以下几个方面：系统总体功能和业务结构、硬件系统需求、软件系统需求、硬件系统和软件系统之间的接口需求。

常用的系统分析方法包括结构化分析、原型化方法和面向对象的分析。

第7章

系统分析文档

7.1系统/子系统需求规格说明

引言 引用文件

需求：要求的状态和方式；需求概述；系统能力需求；系统外部接口需求；系统内部接口需求；系统内部数据需求；适应性需求；安全性需求；保密性和私密性需求；操作需求；可使用性、可维护性、可移植性、可靠性和安全性需求；故障处理需求；系统环境需求；计算机资源需求；系统质量需求；设计和构造的约束；相关人员需求；相关培训需求；相关后勤需求；包装需求；其他需求；需求的优先次序和关键程度 合格性规定 需求可追踪性 非技术性需求 尚未解决的问题 注解 附录

7.2接口需求规格说明

引言 引用文件 需求

合格性规定 需求可追踪性 注解 附录

7.3软件需求规格说明

引言 引用文件

软件需求：要求的状态和方式；需求概述；需求规格；软件能力需求；软件外部接口需求；软件内部接口需求；软件内部数据需求；适应性需求；安全性需求；保密性和私密性需求；软件环境需求；计算机资源需求；软件质量需求；设计和实现的约束；数据需求；操作需求；故障处理需求；算法需求；相关人员需求；相关培训需求；相关后勤需求；包装需求；其他需求；需求的优先次序和关键程度 合格性规定 需求可追踪性 尚未解决的问题 注解 附录

7.4小节

根据《GB/T 8567-2006 计算机软件文档编制规范》（Specification for computer

  

 

     

    



 software documentation），系统分析文档主要包括系统/子系统需求规格说明（SSS）、接口需求规格说明（IRS）和软件需求规格说明（SRS）。系统/子系统需求规格说明（SSS）为一个系统或子系统指定需求以及保证每个需求得到确认所使用的方法。

接口需求规格说明（IRS）描述为实现一个或多个系统、子系统、硬件配置项（HWCI）、计算机软件配置项（CSCI）、用户

软件需求规格说明（SRS）描述对计算机软件的需求以及确保每个需求得到确认所使用的方法。

第8章

系统设计基础 8.1系统设计概述

 8.1.1 系统级设计决策

系统级设计决策，是指系统行为的设计决策（忽略其内部实现，从用户角度出发，描述系统将怎样运转以满足需求）和其他对系统部件的选择和设计产生影响的的决策。系统级设计决策内容：有关系统接收的输入和产生的输出的设计决策；对每个输入或条件进行响应的系统行为的设计决策；系统数据库/数据文件如何呈现给用户的设计决策；为满足安全性、保密性和私密性需求所选用的方法；硬件或硬软件系统的设计和构造选择；为了响应需求而作出的其他系统级设计决策。

 8.1.2 系统架构设计

总体设计

系统部件设计 动态交互设计 接口设计

 8.1.3 运行设计

系统初始化——说明本系统的初始化过程。

运行控制——说明对系统施加不同的外界运行控制时所引起的各种不同的运行组件组合、每种运行所经历的内部组件和支持软件、每一种外界运行控制的方式方法和操作步骤、每种运行组件组合将占用各种资源的情况以及系统运行时的安全控制。运行结束——说明本系统运行的结束过程。

 8.1.4 系统出错处理设计

出错信息——包括出错信息表、故障处理技术等。补救措施——说明故障出现后可能采取的补救措施。

 8.1.5 系统维护设计

检测点的设计——说明在系统中专门安排用于系统检查与维护的检测点。

检测专用组件的设计——说明在系统中专门安排用于系统检查与维护的专用组件。

8.2软件设计概述

 8.2.1 软件级设计决策

软件级设计决策是指软件行为的设计决策（忽略其内部实现，从用户角度出发，描述软件将怎样运转以满足需求）和其他影响组成该软件的软件配置项的选择与设计的决策。

软件级设计决策内容：有关软件接收的输入和产生的输出的设计决策；对每个输入或条件进行响应的软件行为的设计决策；有关数据库/数据文件如何呈现给用户的设计决策；为满足安全性、保密性和私密性需求所选用的方法；为响应需求而作出的其他软件级设计决策。

 8.2.2 软件架构设计

           程序结构设计

全局数据结构设计 软件配置项设计 动态交互设计 接口设计

 8.2.3 软件详细设计

软件配置项设计决策

软件配置项设计中的约束、限制或非常规特征 软件配置项使用的编程语言考虑 软件配置项使用的过程式命令选取

软件配置项的局部数据与软件配置项的输入或输出数据设计 软件配置项的逻辑设计

8.3设计原则  8.3.1 组件化

组件的可分解性 组件的可组装性 组件的可理解性 组件的连续性 组件的保护性

 8.3.2 抽象

抽象就是抽出事物的本质特性而暂时忽略其细节，使得不同的事物可以当作相同的事务来处理。

软件工程过程的每一步都是对软件解法的抽象层次的一次精化。

软件设计中的抽象机制主要包括类、模板、过程抽象、数据抽象和控制抽象。

 8.3.3 内聚与耦合

内聚是指一个组件内各个元素彼此结合的紧密程度 内聚种类（由低到高排列）：偶然内聚；逻辑内聚；瞬时内聚；过程内聚；通信内聚；顺序内聚；功能内聚

耦合是指一个软件结构内不同组件之间的互连程度 耦合种类（由高到低排列）：内容耦合；公共耦合；外部耦合；控制耦合；标记耦合；数据耦合；非直接耦合

组件的高内聚、低耦合原则称为组件独立原则

 8.3.4 封装与信息隐蔽

第一，组件是其全部属性和全部服务紧密结合而形成的一个不可分割的整体。

第二，组件是一个不透明的黑盒子，表示组件状态的数据和实现操作的代码都被封装在黑盒子里面。使用一个组件的时候，只需知道它向外界提供的接口形式，无须知道它的数据结构细节和实现操作的算法。

 8.3.5 启发式规则

深度、宽度、扇出与扇入 作用域和控制域 功能的可预测性

8.4设计视图

 8.4.1 架构视图（静态视图）

架构描述语言（ADL）              

  



                  

  类图与对象图 组件图

协作责任卡（CRC）部署图

实体-联系图（E-R图）接口描述语言（IDL）结构图

Jackson结构图

 8.4.2 行为视图（动态视图）

活动图 协作图 顺序图 数据流图

决策表和决策图

流程图和结构化流程图 状态图

形式化描述语言 伪码

8.5小节

系统设计是定义一个系统或软件的架构、组件、接口和其它特征的过程。包括系统级设计决策、系统架构设计、运行设计、系统出错处理设计和系统维护设计。

软件设计主要包括软件级设计决策、软件架构设计（概要设计）与详细设计。软件架构设计的主要任务是程序结构设计、全局数据结构设计、软件配置项设计、动态交互设计和接口设计。软件详细设计是指每一个软件配置项的具体设计。

组件化、抽象、高内聚与低耦和、封装与信息隐蔽是软件设计的基本原则。软件设计视图通常可分为架构视图（静态视图）和行为视图（动态视图）两类。第9章

系统设计方法 9.1结构化设计

 9.1.1 结构化设计方法概述

分析系统的总体需求，并将需求逐步分解为基本、具体的功能。确定每个功能应当记录的数据。

列出系统中应提供的各项基本功能，并分析各项基本功能之间的耦合关系，根据高内聚、低耦和的原则分配到系统中适当的模块中。

 9.1.2 系统结构图

模块 调用 数据 控制 转接符号

 9.1.3 系统结构图分类

变换流与事务流 变换型系统结构图 事务型系统结构图   

       

 混合型系统结构图

9.2面向数据结构的设计

 9.2.1 面向数据结构的设计概述

分析并建立适合系统的数据结构；

根据数据结构在相应的层次建立程序结构；

罗列出程序中用到的各种基本操作，并将这些基本操作分配到程序结构中合适的模块中。

 9.2.2 Jackson图

顺序结构 选择结构 重复结构

改进的Jackson图

 9.2.3 Jackson方法

分析并确定输入和输出数据的逻辑结构，并利用Jackson 找出输入和输出数据结构中存在对应关系的数据单元。从描绘数据结构的Jackson图导出描绘程序结构的Jackson

列出所有操作和条件(包括分支条件和循环结束条件)，并且把它们安排到程序结构图的适当位置。用伪代码表示。

9.3面向对象的设计

 9.3.1 面向对象的设计概述

面向对象设计的基本思想是通过建立和客观实际相对应的对象，并通过这些对象的组合来创建具体的应用。

面向对象设计具有基于抽象、信息隐藏、功能独立和模块性构造系统的能力。

对于面向对象的系统，可以定义一个四个层次的设计金字塔：子系统层；类及对象层；消息层；责任层。

 9.3.2 面向对象设计技术

 Coad/Yourdon方法  Booch方法  OMT方法  

 9.3.3 面向对象设计过程

系统设计过程：将分析模型划分为子系统；子系统分配及与问题的并发性；任务管理；数据管理；资源管理；人机界面；子系统间通信

对象设计过程：对象描述；算法与数据结构设计；接口设计与模块化

9.4设计模式

 9.4.1 设计模式概述

设计模式就是将面向对象软件的设计经验记录下，可供设计者能够复用的设计方案。设计模式极大提高了面向对象软件开发的效率，降低了软件的复杂度。

在软件设计中使用设计模式，将使用开发出来的软件更容易理解、更容易维护、更容易扩展，使用设计模式同时也能够提高开发团队和个人的开发能力。

 9.4.2 设计模式基本组成

模式名称：惟一标识一个设计模式。问题：描述应该在何时使用该模式。  

        

  

  

 

 解决方案：描述设计的组成要素，以及它们之间的相互关系及各自的职责与相互之间协作的方式。

 效果：描述应用设计模式的效果，以及使用设计模式必须考虑的限制和约束因素。

 9.4.3 设计模式分类

 面向对象模式  代码模式

 框架应用模式

 创建型模式、结构型模式与行为型模式  类模式与对象模式

 9.4.4 如何使用设计模式

 针对接口编程，而不是针对实现编程  优先使用对象组合，而不是类继承  找出变化并封装

9.5小节

 系统设计是一系列迭代的过程，主要任务包括数据结构、体系结构、接口及过程细节的设计等，而设计方法是软件设计活动中实现设计模型的方法。 系统设计方法主要包括面向过程的结构化设计方法、面向数据结构的设计，以及面向对象的设计方法与设计模式。

第10章

数据库设计 10.1数据建模

 10.1.1 数据模型分类

 概念数据模型  结构数据模型  物理数据模型

 10.1.2 实体-联系（E-R）模型

 实体  属性  联系  实体型  实体集  键  域

 10.1.3 数据模型

 层次数据模型（hierarchical model） 网状数据模型（network model） 关系数据模型（relational model）

 面向对象模型（object oriented model）

10.2数据规范化

 10.2.1 数据规范化的基本概念

 函数依赖

 非平凡函数依赖  完全函数依赖  部分函数依赖

 传递函数依赖  键

 10.2.2 范式

    第一范式（1NF）第二范式（2NF）第三范式（3NF）BC范式（BCNF）

10.3数据库设计过程  10.3.1 数据库需求分析

                     数据边界的确定 数据环境的确定 数据内部关系 数据字典

数据性能需求

数据需求分析说明书

 10.3.2 数据库概念设计

概念设计与概念模型 概念设计的主要方法 分解与抽象 局部概念模式 全局概念模式

 10.3.3 数据库逻辑设计

初始模式的形成 子模式设计

应用程序概要设计 模式评审 修正模式

 10.3.4 数据库物理设计

存储记录结构设计 确定数据存放位置 存取方法设计

完整性和安全考虑 程序设计

10.4小节

 数据库系统普遍采取数据模型表示和处理客观事物的数据特征与信息。数据模型主要由数据结构、数据操作和完整性约束三部分组成，从抽象层次上描述和模拟了系统的静态特征、动态行为和约束条件。

 关系数据库中的关系必须满足一定的要求，即满足不同的范式。目前关系数据库中常用的范式包括：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和BCNF。 数据库设计主要包括需求分析、概念设计、逻辑设计和物理设计等几个阶段。

第11章

用户界面设计

11.1基本概念

  

         

     

           

 11.1.1 界面设计目标

可用性目标：可行性、有效性、易学性、易记性、安全性、通用性

用户体验目标：令人满意、令人愉快、引人入胜、富有启发、激发创造„„

可用性目标主要从客观角度来评价系统界面，而用户体验目标则是从用户主观感受的角度来评价系统界面。

 11.1.2 界面设计原则

可视性：将系统功能呈现得一目了然。

反馈性：返回与活动相关的信息，以便用户能够继续这个活动。限制性：将用户的行为限制在一定的范围内。

对应性：明确系统某个控制与其控制效果之间的对应关系。一致性：用相似的元素表现相似的操作或相似的任务。启示性：界面元素应给予用户某种提示。

 11.1.3 界面设计过程

标识出用户的真实需要并建立需求模型 设计出候选方案

构建或实现设计的原型版本 对界面设计进行评估

11.2界面设计技术

 11.2.1 界面设计分析技术

GOMS模型及GOMS击键层模型 Hick律 Fitts律

 11.2.2 界面设计方法

原型设计方法

以用户为中心的设计方法 用户界面设计的支持工具

11.3界面设计评估

 11.3.1 构造性评估与总结性评估

构造性评估：在设计过程中对所设计的系统或产品界面进行评估以确保其满足用户需求。

总结性评估：对已经完成的产品或系统界面进行评估。

 11.3.2 评估范型

快速评估 可用性测试 实地研究 预测性评估

 11.3.3 评估方法与技术

观察用户

征求用户意见 征求专家意见 用户测试

用户执行情况的分析模型

 11.3.4 评估框架

明确（Determine）

        

发掘（Explore）选择（Choose）标识（Identify）决定（Decide）评估（Evalute）

11.5小节

用户界面体现了用户利用系统完成任务的方式以及系统对用户行为的响应方式，一个没有良好的用户界面设计的系统很可能会成为一个没有用户的系统。可用性目标与用户体验目标。

界面设计的量化模型：GOMS模型及其子模型-击键层模型，Hick律和Fitts律。构造性评估与总结性评估。

第12章

系统设计文档

12.1系统/子系统（结构）设计说明

                         引言 引用文件

系统级设计决策

系统体系结构设计：总体设计；系统部件设计；动态交互设计；接口设计 运行设计

系统出错处理设计 系统维护设计 尚未解决的问题 需求的可追踪性 注解 附录

12.2

接口设计说明

引言 引用文件 接口设计

需求的可追踪性 注解 附录

12.3

软件（结构）设计说明

引言 引用文件

软件级设计决策

软件体系结构设计：程序结构设计；全局数据结构设计；软件配置项设计；动态交互设计；接口设计 软件详细设计 需求的可追踪性 注解 附录

12.4数据库设计说明

        

    

引言 引用文件

数据库级设计决策 数据库详细设计

用于数据库操纵或访问的软件配置项的详细设计 需求的可追踪性 注解 附录

12.5

小节

根据《GB/T 8567-2006 计算机软件文档编制规范》，系统设计文档主要包括系统/子系统设计（结构设计）说明（SSDD）、接口设计说明（IDD）、软件（结构）设计说明（SDD）和数据库设计说明（DBDD）。

系统/子系统设计（结构设计）说明（SSDD）描述了系统（或子系统）的系统级（或子系统级）设计决策与体系结构设计。

接口设计说明（IDD）描述了一个或多个系统、子系统、硬件配置项（HWCI）、计算机软件配置项（CSCI）、用户或其他系统部件的接口特性。

软件（结构）设计说明（SDD）描述了计算机软件系统的软件级设计决策、软件体系结构设计（概要设计）与详细设计。

数据库（顶层）设计说明（DBDD）描述了数据库的设计。系统设计文档可以使用自然语言，可以使用形式化语言，也可以根据具体的系统设计方法使用各种图形工具，还可以根据实际情况混合使用多种表现形式。

第四篇：系统分析与设计 期末考试

10.在一个课程注册系统中，定义了类CourseSchedule和类Course，并在类CourseSchedule中定义了方法add(c: Course)和方法remove(c: Course)，则类CourseSchedule和类Course之间的关系是：（）A.泛化（generalization）关系 B.组合（composition）关系 C.依赖（dependency）关系 D.包含（include）关系 13.进行企业系统规划，哪种规划方法使目标识别比较全面

A、企业系统规划法 B、关键成功因素法

C、战略目标集转化法 D、成本效益分析法 14.系统开发的生命周期中不包括下列哪个阶段（）A.系统规划 B.系统分析 C.系统设计 D.系统实施

19.面向对象程序设计将描述事物的数据与()封装在一起,作为一个相互依存、不可分割的整体来处理。A.信息 B.数据隐藏 C.对数据的操作 D.数据抽象 22.属于系统设计阶段的工具是（）：

A.数据流程图 B.处理流程图 C.系统流程图 D.HIPO图

23.进行企业系统规划，哪种规划方法可以形成一套完整的信息系统结构方案（）A.企业系统规划法 B.关键成功因素法 C.战略目标集转化法 D.成本效益分析法

30.导出模块结构图的基础是（）

A.业务流程图 B.数据流程图 C.处理流程图 D.层次结构图

32.（）是从用户使用系统的角度描述系统功能的图形表达方法。

A.类图 B.对象图 C.序列图 D.用例图

35.UML中，对象行为是通过交互来实现的，是对象间为完成某一目的而进行的一系列消息交换。消息序列可用两种图来表示，分别是（D）

A.状态图和顺序图 B.活动图和协作图

C.状态图和活动图 D.顺序图和协作图

36.用例（Use-case）用来描述系统在事件做出响应时所采取的行动。用例之间是具有相关性的。在一个“订单输入子系统”中，创建新订单和更新订单都需要检查用户帐号是否正确。那么，用例“创建新订单”、“更新订单”与用例“检查用户帐号”之间是（A）关系。

A.包含（include）B.扩展（extend）

C.分类（classification）D.聚集（aggregation）

1、组成UML有三种基本的建筑块是：（A），事物和图

A、关系 B、类 C、用例 D、实体

2、UML体系包括三个部分：UML基本构造块，（A）和UML公共机制

A、UML规则 B、UML命名 C、UML模型 D、UML约束

4、（A）模型的缺点是缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题

A、瀑布模型 B、原型模型 C、增量模型 D、螺旋模型

5、下面哪个不是UML中的静态视图（A）

A.状态图 B.用例图 C.对象图 D.类图

6、（A）技术是将一个活动图中的活动状态进行分组，每一组表示一个特定的类、人或部门，他们负责完成组内的活动。

A、泳道 B、分叉汇合 C、分支 D、转移

7、下列关于状态图的说法中，正确的是（C）

A.状态图是UML中对系统的静态方面进行建模的五种图之一。B.状态图是活动图的一个特例，状态图中的多数状态是活动状态

C.活动图和状态图是对一个对象的生命周期进行建模，描述对象随时间变化的行为。D.状态图强调对有几个对象参与的活动过程建模，而活动图更强调对单个反应型对象建模

8、对反应型对象建模一般使用（A）图

A、状态图 B、顺序图 C、活动图 D、类图

12、（D）是系统中遵从一组接口且提供实现的一个物理部件，通常指开发和运行时类的物理实现 A、部署图 B、类 C、接口 D、组件

13、关于协作图的描述，下列哪个不正确（B）

A.协作图作为一种交互图，强调的是参加交互的对象的组织； B.协作图是顺序图的一种特例 C.协作图中有消息流的顺序号；

D.在ROSE工具中，协作图可在顺序图的基础上按“F5”键自动生成； 8定义大多数的需求和范围的工作是在UP中的 B 阶段完成的。A初始阶段 B细化阶段 C构造阶段 D提交阶段

1.信息系统设计是系统开发的重要阶段，进行系统设计的主要依据应是（）。A、可行性研究报告B 系统分析报告

C、系统调查报告 D、系统规划报告

3.在系统总体结构设计时，应采纳什么样的方法（）。A、程序设计 B、结构化设计 C、由里向外 D、自底向上 4.结构化设计的基本思想是（）。

A、模块化 B、集成化 C、自底向上，逐步求精 D、规范化

5.在结构化生命周期法中，系统分析和系统实施之间的阶段是（）。A、详细设计 B系统设计 C、需求分析 D、编程调试 6.对于结构化设计思想的描述哪一项是错误的（）。

A、在结构化设计中，模块的功能应当简单明确，易于理解 B、自顶向下，逐步求精

C、设计者应先设计顶层模块

D、越下层模块，其功能越具体，越复杂 8.系统设计阶段的主要目的是（）。

A、设计新系统的目标 B 将系统逻辑方案转换成物理方案 C、代码设计 D、程序设计 19.结构化设计方法中绘制模块结构图的基础是（）。A 数据流程图 B、数据关系图 C、数据结构图 D、业务流程图 29.系统设计阶段的主要工作内容之一是（）。

A、程序设计 B、购置计算机 C、画出数据流程图 B、规定处理过程 31.系统的呑吐量指的是（）。

A、每天的数据输出量 B、每秒数据的处理量 C、每日数据的输入量 D、每秒执行的作业数

33.在系统物理配置方案的设计中，系统的（）可以用连续工作时间来表示。A、吞吐量 B、响应时间 C 可靠性 D、地域范围 34.计算机和网络系统配置说明，应包含在()中。

A、系统规划说明书 B、系统设计说明书 C、系统实施说明书 D、系统分析说明书 35.属于系统详细设计工作的是（）。

A、输入输出设计 B、系统平台设计 C、系统结构设计 D、程序设计 39.系统设计报告的主要作用是作为（）的依据。A、系统规划 B、系统分析 C、系统实施 D、系统评价

1.B 3.B 4.A 5.B 6.D8.B 19.A 29.D 31.D 33.C 34.B 35.A 39.C 11.系统设计阶段需要从数据流程图导出模块结构图。B.生命周期结构(Lifecycle Architecture)里程碑 4．系统实施的主要活动包括（D）。C.初始功能(Initial Operational)里程碑 A、编程、系统调试 B、系统安装 C、新旧系统转换 D、以上都是 1．系统实施是以（B）为依据的。

A、系统分析文档资料 B、系统设计文档资料

C、系统分析和设计文档资料 D、数据流程图

7.一般子系统的划分是在系统()阶段,根据对系统的功能/数据分析的结果提出的.A.需求分析 B.逻辑阶段 C.总体设计 D.详细设计 答案: A 4.业务系统规划法(BSP)的核心是()A.明确企业目标 B.定义(识别)业务过程 C.进行数据分析 D.确定信息结构 答案: C 7.一般子系统的划分是在系统()阶段,根据对系统的功能/数据分析的结果提出的.A.需求分析 B.逻辑阶段 C.总体设计 D.详细设计 答案: A 4.业务系统规划法(BSP)的核心是()A.明确企业目标 B.定义(识别)业务过程 C.进行数据分析 D.确定信息结构 答案: C 12.RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段(Inception),细化阶段(Elaboration),构造阶段(Construction)和交付阶段(Transition),每个阶段结束于一个主要的里程碑(Major Milestones).构建阶段结束时是第三个重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目标(Lifecycle Objective)里程碑

D.产品发布(Product Release)里程碑 答案: C

14.信息系统开发的结构化方法的一个主要原则是().A.自顶向下原则 B.自底向上原则 C.分步实施原则 D.重点突破原则 答案: A

16.一般来说,占维护工作比例最高的是().A.纠错性维护 B.适应性维护 C.完善性维护 D.预防性维护 答案: C

17.用户开发应用系统的主要手段是().A.生命周期法 B.原型法 C.第四代语言 D.面向对象方法 答案: A

19.系统规划的主要任务包括().A.明确组织的信息需求,制定系统总体结构方案 B.对系统进行经济,技术和使用方面的可行性研究 C.选择计算机和网络系统的方案 D.确定软件系统的模块结构 答案: A

20.系统设计阶段的主要成果是().A.用户的决策方针 B.用户的分析方案 C.系统设计说明书 D.系统总体设计方案

答案: C

21.信息系统建设的结构化方法中用户必须参与的原则是用户必须参与().A.系统建设中各阶段工作 B.系统分析工作 C.系统设计工作 D.系统实施工作 答案: A

22.结构化生命周期法的主要缺点之一是().A.系统开发周期长 B.缺乏标准,规范

C.用户参与程度低 D.主要工作集中在实施阶段 答案: A 24.系统分析工作的全面总结和主要成果是().A.可行性研究报告B.数据词典 C.系统说明书 D.系统详细调查报告 答案: A 28.生命周期法的特点之一是().A.整个系统的开发工作是非劳动密集型的 B.系统开发时间短

C.对用户需求的变更能做出迅速响应 D.适合大型复杂系统 答案: C 30.系统维护中要解决的问题来源于().A.系统分析阶段 B.系统设计阶段 C.系统实施阶段 D.三者都包括

答案: D 38.下面哪一项不是系统设计阶段的主要活动().A.系统总体设计 B.系统硬件设计 C.系统详细设计 D.编写系统实施计划 答案: D 39.对于结构化设计思想的描述哪一项是错误的().A.在结构化设计中,模块的功能应当简单明确,易于理解

B.自顶向下,逐步求精

C.设计者应先设计顶层模块

D.越下层模块,其功能越具体,越复杂

答案: D 73.在系统生命周期的各阶段中,花费费用和人力投入最多的阶段是().A.分析与设计 B.编制程序 C.测试程序 D.系统维护

答案: A 78.在UML提供的图中,()用于描述系统与外部系统及用户之间的交互.A.用例图 B.类图 C.对象图 D.部署图

答案:A 79.在UML提供的图中,()用于按时间顺序描述对象间的交互.A.网络图 B.状态图 C.协作图 D.序列图（顺序图）答案:D 96.系统分析报告的主要作用是().A.系统规划的依据 B.系统实施的依据 C.系统设计的依据 D.系统评价的依据 答案:C 95.绘制系统流程图的基础是().A.数据关系图 B.数据流程图 C.数据结构图 D.功能结构图 答案:B

9.信息系统开发的步骤是:在系统规划后,循进行_____, _____, _____ ,_____ 工作.答案: 系统分析 系统设计 系统构建与实施 系统评价 13.信息系统规划有哪些方法

答:用于企业信息系统规划的方法主要有战略分析法,即关键成功因素法(Critical Success Factors,CSF);企业分析法,即企业系统规划法(Business System Planning,BSP);基于BPR的信息系统战略规划方法.其他的方法还有战略目标集转化法(Strategy Set Transformation,SST),企业信息分析与集成技术(BIAIT),投资回收法(R01)等.12.RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段(Inception),细化阶段(Elaboration),构造阶段(Construction)和交付阶段(Transition),每个阶段结束于一个主要的里程碑(Major Milestones).构建阶段结束时是第三个重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目标(Lifecycle Objective)里程碑 B.生命周期结构(Lifecycle Architecture)里程碑 C.初始功能(Initial Operational)里程碑 D.产品发布(Product Release)里程碑

答案: C

14.信息系统开发的结构化方法的一个主要原则是().A.自顶向下原则 B.自底向上原则 C.分步实施原则 D.重点突破原则 答案: A

16.一般来说,占维护工作比例最高的是().A.纠错性维护 B.适应性维护 C.完善性维护 D.预防性维护 答案: C

17.用户开发应用系统的主要手段是().A.生命周期法 B.原型法 C.第四代语言 D.面向对象方法

答案: A

19.系统规划的主要任务包括().A.明确组织的信息需求,制定系统总体结构方案 B.对系统进行经济,技术和使用方面的可行性研究 C.选择计算机和网络系统的方案 D.确定软件系统的模块结构 答案: A

20.系统设计阶段的主要成果是().A.用户的决策方针 B.用户的分析方案 C.系统设计说明书 D.系统总体设计方案 答案: C

21.信息系统建设的结构化方法中用户必须参与的原则是用户必须参与().A.系统建设中各阶段工作 B.系统分析工作 C.系统设计工作 D.系统实施工作 答案: A 22.结构化生命周期法的主要缺点之一是().A.系统开发周期长 B.缺乏标准,规范

C.用户参与程度低 D.主要工作集中在实施阶段 答案: A 24.系统分析工作的全面总结和主要成果是().A.可行性研究报告B.数据词典 C.系统说明书 D.系统详细调查报告 答案: A 28.生命周期法的特点之一是().A.整个系统的开发工作是非劳动密集型的 B.系统开发时间短

C.对用户需求的变更能做出迅速响应 D.适合大型复杂系统 答案: C 30.系统维护中要解决的问题来源于().A.系统分析阶段 B.系统设计阶段 C.系统实施阶段 D.三者都包括 答案: D 38.下面哪一项不是系统设计阶段的主要活动().A.系统总体设计 B.系统硬件设计 C.系统详细设计 D.编写系统实施计划

答案: D 39.对于结构化设计思想的描述哪一项是错误的().A.在结构化设计中,模块的功能应当简单明确,易于理解

B.自顶向下,逐步求精

C.设计者应先设计顶层模块

D.越下层模块,其功能越具体,越复杂

答案: D 73.在系统生命周期的各阶段中,花费费用和人力投入最多的阶段是().A.分析与设计 B.编制程序 C.测试程序 D.系统维护

答案: A 78.在UML提供的图中,()用于描述系统与外部系统及用户之间的交互.A.用例图 B.类图 C.对象图 D.部署图 答案:A 79.在UML提供的图中,()用于按时间顺序描述对象间的交互.A.网络图 B.状态图 C.协作图 D.序列图（顺序图）

答案:D

96.系统分析报告的主要作用是().A.系统规划的依据 B.系统实施的依据 C.系统设计的依据 D.系统评价的依据 答案:C

95.绘制系统流程图的基础是().A.数据关系图 B.数据流程图 C.数据结构图 D.功能结构图 答案:B

9.信息系统开发的步骤是:在系统规划后,循进行_____, _____, _____ ,_____ 工作.答案: 系统分析 系统设计 系统构建与实施 系统评价 13.信息系统规划有哪些方法

答:用于企业信息系统规划的方法主要有战略分析法,即关键成功因素法(Critical Success Factors,CSF);企业分析法,即企业系统规划法(Business System Planning,BSP);基于BPR的信息系统战略规划方法.其他的方法还有战略目标集转化法(Strategy Set Transformation,SST),企业信息分析与集成技术(BIAIT),投资回收法(R01)等.2.信息系统规划是指对组织目标、组织现状进行分析，从而制定指导信息系统建设的总体规划和信息系统长期发展展望。在众多的信息系统规划方法当中，具有代表性的主要有 企业系统规划法、战略目标转移法、关键成功因素法。

4.信息系统建设的特点决定了信息系统建设要做大量复杂和细致的工作。信息系统建设主要包括 信息系统规划、信息系统开发、信息系统维护 和 信息系统管理 四方面的工作。

1． UML统一建模语言共定义了哪两类、哪八种图形？

答：（1）静态结构图：类图，对象图，构件图，实施图

（2）动态行为图：用例图，顺序图，协作图，状态图，活动图

2.在下图所示的用例分析类图中，请指出各个概念类属于哪一类，并分别解释三种概念类的特点及概念。“售书处理”的用例分析类图书目售书员售书界面产生待售图书待售图书开书单打印进程架存图书出售图书售出图书答：属于实体类的有：书目、架存图书、代售图书、售出图书。

属于边界类的有：售书界面。

属于控制类的有：产生待售图书、出售图书、开书单。三种概念类的特点及概念：

特点：概念类面向功能需求，一般不考虑性能要求，具有突出业务领域、突出概念性及大粒度的特征。概念：（1）实体类是信息系统表示客观实体的抽象要素。它一般对应着在业务领域中的客观事物，或是具有较稳定信息内容的系统元素。（2）边界类是描述系统与参与者之间交互的抽象要素。边界类只是对信息系统与参与者之间交互的抽象建模，并不表示交互的具体内容及交互界面的具体形式。

（3）控制类是表示信息系统对其他对象实施协调处理、逻辑运算的抽象要素。3．请根据下图所示的概念模型，将其转换为逻辑模型(即写出其关系模式)。

编号姓名读者职业电话住址邮编*待售图书*类别单价出版日期书号架位架存册数书号书名作者出版社1选书*架存图书*11书目书单号册数折扣率交款标记售书员答：根据其E-R图，其关系模式为：

读者(编号，姓名，职业，电话，住址，邮编)架存图书(书号，架位，架存册数)

待售图书(书单号，册数，折扣率，交款标记，售书员)书目(书号，书名，作者，出版社，出版日期，类别，单价)9.如图，是在网上商店系统经理的用例图如下：

网上购物系统顾客的功能用例

1.单一职责原则（Single Responsibility Principle, SRP）：

 There should never be more than one reason for a class to change. 应该有且仅有一个原因引起类的变更 2.里氏替换原则 最正宗的定义：

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。）里氏替换原则

通俗讲，只要父类出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是反过来就不行了，有子类出现的地方，父类未必就能适应。3.迪米特法则

迪米特法则的定义：

迪米特法则（Law of Demeter, LoD）也称为最少知识原则，一个对象应该对其他对象有最少的了解。

一个类应该对自己需要耦合或调用的类知道得最少，被耦合或调用的类的内部如何复杂都和我没有关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。4.开闭原则

开闭原则的定义：

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

一个软件实体应该通过扩展来实现变化，而不是通过修改已有的源代码来实现变化。5.依赖倒置原则

依赖倒置原则包含三层含义：

 高层模块不应该依赖低层模块，两者都应该依赖其抽象；

  抽象不应该依赖细节； 细节应该依赖抽象。

在java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。6.接口隔离原则

接口隔离原则定义：

  客户端不应该依赖它不需要的接口；

类间的依赖关系应该建立在最小的接口上。

建立单一接口，不要建立臃肿庞大的接口，接口尽量细化，同时接口中的方法尽量少。它要求“尽量使用多个专门的接口”。专门接口指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿接口，容纳所有的客户端访问。

1.在RUP中，软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。横轴表示项目的时间维，纵轴以内容来组织为自然的逻辑活动。

第五篇：系统分析与设计心得

读《系统分析与设计方法》一书有感

作为一个软件专业的学生，理解和掌握系统分析与设计的知识是必不可少的。在阅读《系统分析与设计方法》一书中以及加上老师教导，我学到了很多东西，收获不少。

系统就是由若干可以相互区别、由相互联系并且各自独立的单元组成各个子系统之间同样是独立而又相互联系的。系统具有集合性、相关性、目的性、整体性和环境适应性。在开发完成一个软件项目的过程中，系统工程必须经过开发阶段、建造阶段、运行阶段、更新阶段、维护阶段。

系统分析与设计的方法主要包括结构化生命周期法（又称瀑布法）、原型化方法（迭代法）、面向对象方法。

按时间过程来分，开发方法分为生命周期法和原型法，实际上还有许多处于中间状态的方法。原型法又按照对原型结果的处理方式分为试验原型法和演进原型法。试验原型法只把原型当成试验工具，试了以后就抛掉，根据试验的结论做出新的系统。演进原型法则把试好的结果保留，成为最终系统的一部分。

按照系统的分析要素，可以把开发方法分为三类：

①面向处理方法（Processing Oriented，简称PO）。

②面向数据方法（Data Oriented，简称DO）。

③面向对象的方法（Object Oriented，简称OO）。

系统分析和设计应遵循的原则有：

系统开发是面向客户的，应从客户的角度考虑。

诸如系统开发生命周期之类的产品更新换代机构应该在所有的信息系统开发项目中建立起来。

信息系统开发的过程并不是一个顺序的过程，它允许步骤的重叠和倒转等。

如果系统的成功可能性受到很大限制时，应取消整个项目。文档材料是系统开发生命周期中重要的可递交成果，应加以重视。在本书的第一部分中，主要集中于系统分析和设计的整体描述，包括系统分析和设计方法的环境，信息系统构件，信息系统开发，项目管理。期中印象比较深刻的是系统开发过程的能力成熟度模型（CMMI）。信息系统和软件的CMM框架用来帮助改善其系统开发过程的成熟度。CMM包括了五个成熟度等级：初始级、可重复级、已定义级、已管理级、优化级。期中，每个等级都是下一个等级的必须条件。

在软件开发过程中需求分析阶段是至关重要的一个阶段，需求分析阶段可能被称为定义阶段或者逻辑设计阶段。需求分析阶段的第一个任务是确定需求，在这个阶段至少将目标转换成为满足其需要的功能需求和非功能需求的框架。在这个阶段需要交付的成果是功能需求和非功能需求的草稿。在初步定义完了功能需求和非功能需求后，得排列需求的优先次序。如果一个项目落后于进度或者超出预算，知道哪个需求比其他需求更重要可能是很有用的。在排列需求的优先次序中可以使用到时间盒的技术。需求分析并不会真正的技术，因为企业需要具有快速适应不断变化的需求和机会的能力。信息系统不能比企业自身的响应技术还慢。

在学习本书第二部分的时候，我了解到了需求分析在整个项目开发中的作用以及成为整个项目主导的因素。只要好的需求才能设计开发出好的软件项目。在项目开发过程中，我们还可以利用图表的形式来简化方便人员的开发设计。期中有五种图表是系统分析师常用的：类图、用例图、协作图、顺序图、状态图。期中用例图是用例建模的产物，它以图形化的方式将系统描述成用、参与者（用户）及其之间的关系。简单的说就是用直立的小人来表示参与者（用户），用圆圈来表示用例，他们之间以箭头的形式来连接。关系包括了：关联关系、扩展关系、使用关系、依赖关系、继承关系。但是书上没讲到《include》关系，跟老师的讲解有点出路。老师在讲义上通过画图的方式很好的解释了《include》和《extend》的关系。

数据建模这一章节中，我了解了数据建模的含义，它是一种为数据库定义业务需求的技术。数据建模中比较重要的概念有实体和属性之间的关系，关系是连接实体的一个时间，或者仅仅是存在于实体之间的逻辑关系。关系有很多种类，多对多、一对多、一对

一、等等。这些关系的图形化符号记起来很不容易，但是我自己想到了一个比较容易记忆的简单的方法。一个就用 “|”表示，零个就用“0”表示，多个就用“<”表示，然后根据相应的说明来选择。比如零个或一个（0|），一个或多个（|<）。过程建模是一种组织和记录数据的结构和流向的技术，它记录系统的“过程”和有系统的“过程”实现的逻辑、策略和程序。期中也介绍到了数据流图（DFD），数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。我觉得数据流图DFD的最大的优点就是容易阅读，因为数据流图仅有三种符号和一种连接：圆角矩形表示要完成的过程或者工作，正方形表示外部代理（系统的边界），开放的方框表示数据存储（可以是文件或者数据库），箭头表示数据流（可以是输入和输出，或者是表示到过程和来自过程）。统一建模语言UML的目的就是对面向对象系统进行可视化、评述、和文档化。它适用于系统开发从需求规格描述道系统完成后测试的不同阶段（需求分析阶段、分析阶段、设计阶段、编程阶段、测试阶段）。UML2.0的模型主要图包括了：用例图、活动图、类图、对象图、状态机图、组合结构图、交互图、定时图、组件图、部署图和包图。在理解这章的过程中，我感觉比较轻松，但是把一些关系，事件，实体等等用图形化的形式表示出来还是非常难的。用UML设计面向对象系统时候，我们得准确的找到实体类、接口类、控制类、持续类、系统类和设计关系。在面向对象设计的过程中，主要包括了一下活动：对用例模型加以精炼以反映实现环境；建模支持用例情景的对象交互、行为和状态；修改对象模型以反映实现环境。

前面说到需求分析是整个软件项目开发中最重要的一环，其实我觉得可行性分析也是跟需求分析一样的重要。因为信息是一个必须经过检验的重要资本投入，就像市场要检验一个新产品，系统分析员应该考虑投资能够收回吗？是否有其他投资能够带来比预期更高的回报。要说他们的区别，我个人觉得是：可行性分析是要决定“做还是不做”。需求分析是要决定“做什么，不做什么”。可行性分析报告有六个准则：运行可行性、文化可行性、技术可行性、进度可行性、经济可行性。只有进行了可行性分析报告，才能够确定企业是否要 做这个项目。如果说在可行性报告中显示没有成功的可能，那么就没有必要再做需求分析了，整个项目就不会做下去了。进行可行性分析报告可以避免项目中途告终的结果，在系统开发过程中举足轻重。

数据库开发与设计这章，感觉书上讲解的没有老师讲的详细。书上并没有提到范式，但是在课堂上我了解到数据库设计的范式。有第一范式、第二范式、第三范式、BC范式等。等级越高，数据冗余越少，对系统调用数据库更方便。数据库的核心是DBMS，DBMS的核心是数据库引擎，引擎响应专门的命令以创建数据库结构，然后创建、读取、修改和删除数据库中的记录。DBMS使用数据定义语言（DDL）创建记录类型、字段和结构化关系，还定义了数据库视图；DBMS还是用数据处理语言（DML）用来创建、读取、修改和删除数据库中的记录。但是并非所有数据库的DBMS都被要求使用DDL和DML。看完这章，总结了一下建立关系数据库模式的步骤，首先要为每个实体类型建立一张表，然后为每张表选择一个主键，同时增加外键来表示一对多的关系，接着还可以建立几个新表来表示多对多的关系，然后还得定义参照完整性约束，评价模式质量，并且进行必要的改进，最后为每个字段选择适当的数据类型和取值约束。数据库在系统开发的过程中是必不可少的，几乎所有框架类型都得用到数据库，它也是MVC框架的底层核心。

对于本书的还有一个比较映像深刻的就是UI（user interface），用户界面设计。一个良好的用户界面应该为用户提供友好的使用方式，通过用户界面用户可以同应用程序打交道，处理输入并且获得输出。Galitz曾经提出过用户界面设计的原则：理解你的用户及任务、让用户参与界面设计、在实际用户中测试系统、进行迭代设计。记得以前大二的时候学习JAVA的时候，我曾经开发过基于图形用户界面（GUI）的聊天软件，不过当时的界面设计完全设计的是随心所欲，并没有理论作为指导。在学习VB课程的时候学过UAR，简单的了解了一些关于界面友好化设计的原则。这本书也给出了用户界面设计过程的几个步骤：1.以图表形式描述用户界面对话；2.原型化对话和用户界面；3.获得用户反馈；4.如果需要，回到1步或者2步。

最后总结下，虽然我没用把这本书的每一个地方都认真精读，有些地方略读的，但是看完整本书后我收获很大。读完《系统分析与设计方法》这本书再加上老师在课堂上的一些讲解以及以前学习事件过程中的收获，我对于系统分析与设计有了进一步的理解，能高屋建瓴的看待系统分析与设计整个过程的步骤以及增加了一些开发设计中的重要事件的理论知识。

对于系统分析的心得