信息系统分析与设计课件

《信息系统分析与设计》

第一章企业信息系统的各类人员一、数据、信息与信息系统三、系统分析员的职业准备二、信息工作者和现代系统分析员一、数据、信息与信息系统1、信息与信息系统的概念2、信息系统与建模系统六个基本要素：输入、输出、处理、控制、内部结构、边界信息系统:系统基本要素+人+数据+处理过程信息系统的基本特征:数据、功能、行为处理系统控制输入反馈输出边界系统目标系统结构系统功能系统模型：用来模拟现实系统的一种抽象或者近似，是对真实系统的简化表示。几类模型叙述模型物理模型数学模型图示模型二、信息工作者和现代系统分析人员1、信息工作者系统拥有者系统用户系统设计者系统构建者系统分析人员信息系统的范围界定信息系统的需求信息系统设计信息系统的部件商家和咨询者系统分析与设计方法和工具信息工作者是指从事创造、收集、处理、发布及使用信息的人。企业的信息工作者有如下几类：2、现代系统分析员1）什么是系统分析员？他们做什么？2）系统分析员在哪里工作？3）项目经理系统分析员的职责是提高信息系统建设的效率和有效性。

系统分析员是既有企业知识，又懂计算机的人。他研究企业的问题与需求，决定如何最合适地将人员、数据、过程、通信、与信息技术、信息系统建设方案投入企业。系统分析员的工作是解决问题。项目管理：指把各种知识技能、工具和技术以及人力、物力、财力、信息、科学技术和市场资源有效结合，采用规范化的饿管理流程，在规定时间、预算和质量目标范围内完成项目。项目的负责人为项目经理。三、系统分析员的职业准备1、系统分析员需要的技能技术知识和技能商务知识和技能与人沟通的知识和技能诚实和道德一、当前企业中的各种信息系统1、信息系统的分类框架1）管理活动的分类战略规划管理控制知识管理操作管理2）决策过程和分类决策过程、信息需求及相应信息系统决策问题分类应收款订单输入存货控制预算分析工程成本短期预算仓库和工厂位置PERT网络分析系统生产计划现金管理变化分析全面预算预算准备销售和生产合并和购置新生产计划研发计划操作控制管理控制战略计划管理层次非结构化半结构化结构化问题结构化程度3）信息系统基本分类框架非结构化半结构化结构化操作控制层知识管理层战略规划层管理控制层TPSOASMISDSSESSKWS应收帐处理电子会议产品成本预算准备产品设计新市场、新产品事务处理系统办公自动化系统知识工作系统管理信息系统决策支持系统经理支持系统1）事务处理系统TPS(transactionprocessingsystem)

事务处理系统是操作层的数据处理自动化，提高效率的信息系统。典型的TPS：销售订单处理系统、物料需求计划、财务管理系统等。TPS的基本功能：数据处理、数据维护、数据查询、监控功能。TPS是其它信息系统的基础。2、各类典型的信息系统2）管理信息系统MIS（Managementinformationsystem)

MIS是一个由人和计算机等组成的，能进行管理信息的收集、传递、加工、保存、维护和使用的社会技术系统。MIS功能结构库房管理财务管理流动资金成本核算车间调度市场预测合同管理质量管理综合统计设备工具物资供应生产计划共享数据库3）决策支持系统DSS（Decisionsupportsystem)

DSS是能够利用数据和模型来帮助决策者解决非结构化问题的高度灵活的、人机交互式的信息系统。DSS的组成结构TPS外源数据用户DSS数据库用户接口DSS软件系统分析模型OLAP工具数据挖掘工具数据库系统模型库系统人机对话系统DSS的最新发展

DSS=DW+DM+OLAP数据仓库DW

OLAP（on-lineanalyticalprocessing)是对大容量、聚合的数据进行分析，为用户进行动态实时多维分析。联机分析处理OLAP

DW（datawarehouse)是面向主题的、集成的、与时间密切相关的、相对稳定的数据集合，其目的是支持管理人员业务分析与决策制定。数据挖掘DM

DM（Datamining)是从数据库或数据仓库中发现并提取隐藏其中的信息，找出数据间潜在的关联，发现被忽略的要素。4）办公信息系统OSI（officeinformationsystem)

OSI是指通过先进技术的应用，将人们的部分办公业务物化于人以外的各种设备，并由这些设备和办公人员共同完成办公业务的人机信息系统。OSI的组成结构办公信息系统设备软件办公人员各种办公设备输入/输出设备通信设备服务器、工作站系统软件：操作系统、语言处理程序应用软件专用软件通用软件支持软件3、信息系统概念的发展二、信息系统体系结构的框架1、企业的组织结构1）直线型组织结构2）职能型组织结构3）直线参谋型组织结构4）直线职能参谋型组织结构5）事业部制组织结构6）矩阵型组织结构8）网络结构7）多维立体型组织结构1、信息系统体系结构

信息系统体系结构是指一个统一的信息系统框架，通过这个框架，与信息系统有关的各种人员可以从不同角度去组织或观察信息系统的基本结构。系统拥有者系统用户系统设计者系统实施者关注数据关注处理关注接口关注通信系统开发拥有者的数据视图拥有者的处理视图拥有者的接口视图拥有者的通信视图系统用户的数据视图系统用户的处理视图系统用户的接口视图系统用户的通信视图系统设计者的数据视图系统设计者的接口视图系统设计者的处理视图系统设计者的通信视图系统实施者的数据视图系统实施者的接口视图系统实施者的处理视图系统实施者的通信视图系统分析员关注者系统分析与设计

方法学处理过程信息技术与体系结构销售与咨询商三、信息系统的各类建构板块1、数据建构板块和数据视图系统拥有者系统用户系统设计者系统实施者关注数据关注处理关注接口关注通信系统开发商务知识数据需求数据库范式数据库程序系统分析员关注者系统分析与设计

方法学处理过程数据库管理系统销售与咨询商1）系统拥有者的数据视图

商务知识：能够及时准确地从相关信息中洞察到事物本质的能力商务实体：与商务活动有关的有形或无形事物，如：顾客、设备、产品、订单、付款等。商务规则：描述商务实体之间的相互作用。系统拥有者的基本作用是界定系统的范围和要达到的目标。2）系统用户的数据视图商务数据需求是指根据实体、属性、关系和规则表示的用户数据。系统拥有者将商务实体和规则识别出来，系统用户将商务实体和规则进一步延伸为商务数据需求；系统分析员正确地识别和验证用户的商务数据需求。3）系统设计者的数据视图系统设计者将商务数据需求转化到数据库中。因此，系统设计者的数据视图包括数据结构、数据库范式、字段、指针和其他数据库依赖关系。4）系统实施者的数据视图用具体的DBMS实施前面定义的数据库。2、过程建构板块和处理视图系统拥有者系统用户系统设计者系统实施者关注数据关注处理关注接口关注通信系统开发系统分析员关注者系统分析与设计

方法学处理过程应用开发环境销售与咨询商商务功能处理需求应用范式与说明书应用程序1）系统拥有者的处理视图

系统拥有者的处理视图是商务功能，它决定系统的范围。商务功能由商务事件及其响应来识别。2）系统用户的处理视图

系统设计者要明确系统的边界（哪些由系统自动完成），设计系统架构（软、硬件平台），准备软件说明书。3）系统设计者的处理视图

系统用户与商务处理相关。商务处理是响应商务事件的活动。系统用户提供商务处理需求，处理需求是根据活动、数据流和工作流表示的系统用户的商务处理。4）系统实施者的处理视图

用具体程序设计语言编程实现。系统拥有者系统用户系统设计者系统实施者关注数据关注处理关注接口关注通信系统开发系统分析员关注者系统分析与设计

方法学处理过程接口技术销售与咨询商3、接口建构板块和接口视图商务地点接口需求接口说明接口程序1）系统拥有者的接口视图

明确信息系统的接口范围。2）系统用户的接口视图3）系统设计者的接口视图4）系统实施者的接口视图

明确信息系统的用户接口，即：输入、输出形式。

考虑用户接口和系统—系统接口的技术设计问题。

利用接口技术构建、安装、测试和实现用户接口和系统—系统接口。4、网络建构板块和通信视图应用信息系统应用信息系统应用信息系统通信网络交换网络接口处理数据汇聚层接入层系统拥有者系统用户系统设计者系统实施者关注数据关注处理关注接口关注通信系统开发系统分析员关注者系统分析与设计

方法学处理过程网络技术销售与咨询商通信环境通信要求网络体系网络程序一、信息系统开发生命周期1、信息系统开发生命周期的阶段划分1）工作流程系统规划（规划分析师）系统设计（系统设计员）系统实施（系统建造者）系统维护（系统维护人员）系统分析（系统分析员）需求分析规格说明书应用开发项目可行性分析报告系统设计规格说明书产品系统现行系统的缺陷和细节面向过程的观点生命周期是一种用于规划、执行和控制信息系统开发项目组织和管理的方法。是工程学原理在信息系统开发中的具体应用。用户要求需求分析可行性研究评审评审功能模块总体结构数据库设计制定测试计划评审功能模块逐步细化模块接口设计模块过程设计制定模块测试方案评审程序编码测试评审系统维护评审可行性研究报告需求说明书概要设计说明书数据库设计说明书测试计划详细设计说明书测试报告面向控制的观点2）各阶段任务描述系统规划阶段系统分析研究业务目标定义信息结构评估信息域研究业务目标：研究具体的业务需求。定义信息结构：包括数据结构、网络结构、应用结构、人员结构、技术结构评估信息域：方法有：企业系统规划法（BSP法）、战略数据规划法、关键成功因子法主要活动包括：可行性分析、需求分析、系统建模。可行性分析：经济、技术、管理等方面；需求分析：功能需求、性能分析、可靠性、安全性、资源约束等系统设计系统实施包括总体设计和详细设计总体设计：构造软件的总体结构；详细设计：输入/输出、人机界面、数据库设计、程序设计等。编程测试用户培训新旧系统切换系统维护包括修正性维护、适应性维护、完善性维护、预防性维护等2、瀑布模型系统规划系统分析系统设计编码测试系统维护（1）瀑布模型特点强调阶段的划分及其顺序性各阶段工作及其文档的完备性是一种严格线性的、按阶段顺序的、逐步细化的开发模式。致命缺点是；无法早期发现分析、设计阶段的错误。是20世纪70年代由W.Royce提出的一种生命周期模型（2）瀑布模型的基本原理A、用户积极参与用户系统分析员1、提出需求2、反馈需求3、修改需求4、确认需求B、严格划分阶段和活动C、文档标准化文档是软件产品的重要组成部分；文档是通信和交流的手段；文档是对开发过程起控制作用；文档是系统维护的依据E、分而治之的思想系统子系统2子系统1子系统n模块n模块1D、设立检查点每个阶段，都从以下四个方面评估：功能、预算、进度、质量（3）瀑布模型的优缺点优点结构简单明了，应用广泛。需求分析的绝对重要性阶段的顺序性和依赖性逐步求精的结构化方法质量保证措施缺点只适用于需求明确的问题未能解决系统分析到系统设计之间的鸿沟文档编写工作量极大不能很好适应用户需求的变化3、原型化方法（1）快速原型法的概念和思想三类原型抛弃式：目的达到即被抛弃，原型不作最终产品演化式：系统的形成和发展是逐步完成的。每次迭代要对系统重新进行规格说明、设计、实现和评价。增量式：系统是一次一段地增量构造的，与演化式的区别在于是在软件总体设计基础上进行用户需求定义是系统开发非常重要的方面。原型法法有助于获取用户需求。（2）基于快速原型法的系统开发生命周期需求分析快速设计建立原型用户评价原型修改原型生成产品（3）基于快速原型法的优点和缺点优点减少了开发时间，提高了开发效率使信息需求的定义更为直观、简单通过对原型的不断修改和完善，增加了用户的满意度减少了系统开发费用缺点分析和设计的深度不够第一个工作原型可能并非最优方案原型法开发的系统不具灵活性工作原型不易修改（4）应用快速原型法的前提条件系统需求在系统开发前不能准确说明，用户需求变化快；有快速的系统建造工具；需要实际的、可供用户参与的系统模型；用户能够积极参与系统开发；需要有一个原型工作环境；具有一批具有丰富的问题域知识和开发经验的开发人员。4、统一开发过程统一开发过程RUP是由Rational软件公司开发的一种软件工程过程。其目的是在预定的进度和预算范围内,开发出满足用户需要的高质量软件.（1）软件开发问题的症状和原因对用户需求理解不够精确对需求的改变束手无策程序块不兼容、软件不易维护或扩展项目严重缺陷的发现较晚软件质量低劣，性能无法忍受开发组人员各自开发，若有人改变部分软件，将很难再进行重组症状原因模糊不清的交流脆弱的架构，无法控制变化的产生和传播，过度复杂需求、设计和实现之间的不一致等（2）统一过程的特点A、用例驱动以用例获取功能需求，所有用例构成用例模型，描述系统全部功能。B、以体系结构为中心体系结构刻画系统的整体设计，包含重要的静态和动态特征。C、迭代和增量（3）RUP的生命周期A、RUP的二维开发模型（P78）系统开发生命周期由一系列循环组成，每次循环包括4个阶段：启动（初始）、精细规划（细化）、构建（构造）、模型转移（交付）B、开发过程各个阶段主要任务RUP是一个迭代增量式的开发过程，分块逐次开发和提交，每次迭代包含分析、设计、实现和测试的整个过程。启动阶段

该阶段目标是分析问题域，建立完整的体系结构基础，编制项目计划。该阶段为系统开发建立了管理基准，并使项目小组能在构建阶段中进行衡量。主要任务是设计出系统的构架；进行风险分析，并制定相应对策；制定开发计划。精细规划阶段

该阶段目标是为系统建立商业案例,确定项目边界。回答以下问题：明确为用户提供的基本功能（由用例模型表示）系统的架构（即包括的主要子系统）项目开发的计划、费用、风险等。该阶段确定是否启动该项目建构阶段

该阶段由多次渐增开发组成，主要目标是开发应用程序，并集成为产品，测试各功能。该阶段最终确定该项目是否可以在测试环境中部署。所有UML技术均可用于该阶段。用例模型确定工作范围；概念层类图刻画用例的概念；活动图描述用例的工作流情况；交互图描述实现用例时类之间的交互作用关系；包图描述系统的逻辑组成。模型转移阶段

建立企业模型，并在企业模型中定义过程、角色和责任。C、RUP的核心工作流企业模型

该阶段应确保软件对最终用户是可用的。需求确认

理解系统所解决问题的定义和范围。逻辑模型

由设计类和描述组成。设计类构成了具有良好接口的设计包、子系统；描述体现类的对象如何协同实现用例功能。物理模型

以组件形式实现类和对象；以组件为单元进行测试，并将组件集成为系统测试

验证对象间的交互作用；验证组件的正确集成；验证需求被正确实现配置/实现

跟踪和管理软件创建过程中的版本，并成功地将软件分发给最终用户二、信息系统开发方法学1、结构化方法学（1）结构化方法产生的背景（2）结构化方法的基本概念A、基本思想

面向过程；模块化原则；自顶向下，逐层分解；信息隐藏。B、结构化方法的组成

结构化系统分析、结构化系统设计、结构化程序设计结构化分析是以过程为中心，建立用户需求模型的技术；结构化设计是确定软件系统由哪些模块组成，这些模块以什么方式联结在一起。（3）结构化方法的基本原则抽象原则形式化原则分解原则层次组织原则信息隐藏原则模块化原则逻辑独立性原则（4）结构化方法的主要工具2、面向对象方法学（1）什么是面向对象面向对象技术是IT发展的一个里程碑面向对象技术带来软件生产方式的根本变化

面向对象方法使软件生产由人工集约的生产方式转化为资源集约的生产方式。人工集约转变为资源集约的三个条件：模块化可复用性可维护性它的高效性来自两个方面：减少开发者与用户的语义歧意；软件可重用(reuse)。面向对象技术对提高软件质量和效率有显著效果（3）传统开发方法存在的问题问题空间与求解空间不一致

问题空间与求解空间在结构上的同构,即一致性,是人们长期以来一直寻找的系统分析、设计、实现的方法学。面向对象是一种归纳—演绎的方法学，即是一个从特殊到一般（归纳），由一般到特殊（演绎）的过程。结构化方法学造成不一致的两个主要方面：语言鸿沟；冯．诺依曼机与问题域之间的鸿沟。系统分析到系统设计的过渡困难过程模型和数据模型分别建立，忽视系统的行为特征（4）面向对象方法学的发展历史

面向对象方法中，从分析、设计、实施始终讨论的是一个模型，从分析到设计的过渡是一个渐进的、逐步细化的过程。

结构化方法中，过程和数据模型可能存在不一致，且忽视行为特征。面向对象方法将数据、过程、行为三个特征集成在一个模型中。

面向对象方法首先从面向对象语言的研制开始，逐步演化为面向对象分析与设计。OOPL（objectorientedprogramminglanguage)的产生20世纪60年代————Simula67，引入类、继承；20世纪70年代————CLU、并发Pascal、Ada、Modula-2。支持封装；70年代~80年代————SmallTalk-80，标志面向对象程序设计思想的成熟；80年代~90年代————繁荣时期，出现C++、Objective-C、ObjectPascal、Eiffel等90年代后期————SUN推出网络环境下的Java。OOA&OOD的产生：OO方法发展到软件工程的前期阶段（1）Booch方法

给定的抽象层次上识别类和对象；识别这些对象和类的语义；识别这些类和对象之间的关系；实现类和对象

丰富的符号体系：类图、对象图、状态转移图、时态图、模块图、进程图。分析与设计步骤（2）Coad/Yourdon方法

严格区分面向对象分析和面向对象设计。分析阶段：分为5个层次：对象—类型层、结构层、主题层、属性、服务；设计阶段：在分析阶段的5个层次上，又引入4个部分：问题域部分、人机交互部分、任务管理部分、数据管理部分（3）OMT方法

从3个视角描述系统，相应提供三种模型：对象模型、动态模型、功能模型。对象模型：描述对象的静态结构和它们之间的关系，主要概念包括：类、属性、操作、继承、关联、聚集等动态模型：描述系统随时间变化的方面。主要概念包括：状态、子状态和超状态、事件、行为、活动等功能模型：描述系统内部数据值的转变，主要概念包括：加工、数据存储、数据流、控制流、角色等。（4）Jacobson方法

该方法涉及整个软件生命周期，包括：需求分析、设计、实现和测试4阶段。引入usecase（用例）概念，并将用例模型与以下5种模型相结合：领域对象模型：根据领域来表示用例模型；分析模型：通过分析来构造用例模型；设计模型：依据具体化的设计来实现用例模型；测试阶段：测试具体化的用例模型。面向对象方法统一的时代—UML的产生与发展1993年，Rational公司开始设计UML方法；1996年正式推出UML；1997年，被OMG（对象技术组织）推荐为行业标准。UML综合了上述几种方法的优点，统一了语义和表示方法。（5）面向对象的基本概念A、对象、属性、方法和封装

对象：是问题域或实现域中某些事物的一个抽象，它反映该事物在系统中需要保存的信息和发挥的作用；是一组属性和有权对这些属性进行操作的一组服务的封装体。属性：描述对象的具体特征。属性有属性名和属性值。方法：或称服务、操作。是系统为满足用户需求采取的行动，是系统对事件的响应。封装：是把对象的属性和服务结合成一个独立的系统单位，并尽可能隐蔽对象的内部细节。B、对象/类之间的联系

泛化—特化关系整体—部分关系关联关系对象之间的信息传递C、类、继承、泛化—特化

类（又称对象类），是具有相同属性和服务的一组对象的集合，它为属于该类的全部对象提供统一的抽象描述，其内部包括属性和服务两个主要部分。一个类的上层可有超类，下层可有子类，形成类的层次结构。这种层次具有继承性。

继承：子类的对象拥有超类的全部属性与服务，此一特性称为继承性如果类B继承类A，称类A为类B的父类、超类、基类；而类B则称为类A的子类或派生类。

泛化—特化关系也称一般—特殊关系或分类关系。是由一组具有继承关系的类所组成的结构，它通过收集公共特性并把这种特性扩充至特例之中来显示现实世界事件的通用性和专用性。D、整体—部分联系（聚集）

它描述对象之间的组成关系，即一个或一些对象是另一个对象的组成或部分。E、关联

关联有时也称为实例连接或链。实例连接反映了对象和对象之间的静态关系。F、消息和消息传递

消息是一个对象向其他对象发出的服务请求，它应该包含以下信息：提供服务的对象标识、服务标识、输入信息和回答信息。G、多态性

多态性是指一般类中定义的属性或服务被特殊类继承之后，可以具有不同的数据类型或表现出不同的行为。这使得同一属性或服务名在一般类及其各个特殊类中具有不同的语义。（6）面向对象的基本机制A、OO法的基本原理和三大要素

人类认识客观世界的基本原理和过程：原理：先研究事物，而后研究过程两个基本过程：从特殊到一般的归纳过程；从一般到特殊的演绎过程。

面向对象的三大要素：面向对象=对象+对象类+类继承性

面向对象的方法是现实世界在计算机世界的直接映射，是人类认知过程的计算机模拟。B、面向对象方法学中的主要机制

组织机制：对象及属性、整体与部分、类及成员消息通信机制：反映事物之间的相互联系和相互作用。抽象机制：把代表事物属性的数据抽象和代表事物行为的功能抽象有机结合为一体。继承机制（可复用机制）：是表达相似性的机制封装或信息隐藏：对象使用者只知道对象封装界面的信息，对象内部实现是隐蔽的。多态动态绑定类型定义机制（7）面向对象方法与软件复用技术

软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相近软件元素的过程。软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识。这种可复用的元素称为软构件。A、软件复用B、可复用构件

构件是具有一定功能，能够独立工作或同其他构件装配起来协调工作的程序体，构件的使用同他的开发、生产无关。可复用构件既可以从旧的软件中提取，也可以是专门为复用而开发。目前有代表性的构件技术有：CORBA、Java平台、COM+。3、面向对象方法学与结构化方法学的比较结构化方法系统是过程的集合过程与数据实体交互过程接受输入并产生输出面向对象方法系统是交互对象的集合，对象与人或其他对象交互发送与响应消息（1）认识问题的出发点不同A、从逻辑模型的角度看结构化方法从过程的角度建立信息系统模型面向对象方法从对象的角度建立信息系统模型B、从实现的角度看结构化方法程序=算法+数据结构过程模型和数据模型分别建立面向对象方法对象=算法+数据结构程序=对象+对象+….过程（算法）和数据封装成为对象（2）认识系统和描述系统的方式不同A、结构化设计思想应用系统子系统1模块1子系统2子系统n模块n模块2函数1函数n函数2自顶向下，逐步求精的设计方法B、面向对象的设计思想

将设计分成问题域和求解域两层。对问题域进行需求分析时寻找对象及其之间的联系；求解域模型在对象模型基础上增加实现域中的对象获得。C、两者设计思想的差异结构化方法面对怎么做，采取划分子程序、模块等。从大到小，自顶向下面向对象方法首先回答“做什么”，再解决“怎么做”从小到大，自底向上（3）分析到设计的过渡结构化方法分析过程的数据流程图不能自然转换到设计阶段的软件结构图面向对象方法将分析、设计、实现三个过程完整、有机、紧密地结合在一起（4）对变化的适应能力结构化方法侧重于过程建模，过程是系统中极不稳定的因素对变化的适应能力差面向对象方法侧重于对象建模，对象是系统中比较稳定的因素，因此对变化适应能力较好（5）对复用的支持结构化方法缺乏复用标准，对复用支持差面向对象方法对复用支持度高，提供复用机制和复用标准三、计算机辅助软件工程1、CASE的基本概念与发展历史（1）CASE的产生背景（2）CASE的基本概念

基本思想：把系统工程的原理应用到软件的开发维护中去。CASE是能够支持软件开发生命周期一个或多个阶段自动化的计算机程序。它使开发工具与开发方法学统一和结合起来，从开发者的角度支持信息系统各种开发技术和方法的一种技术。（3）CASE的功能支持不同的软件开发方法学支持软件开发生命周期各阶段：上游、下游以及项目管理具有文档出版功能和文字、图形编辑功能。支持软件部件的重用，支持开发信息资源共享。2、CASE体系结构CASE下游CASE上游CASE系统设计系统分析系统规划系统实施系统维护企业战略规划信息系统战略规划其他数据建模过程建模对象建模资源库支持其他结构化英语屏幕/报表设计原型化设计数据库设计测试其他代码生成器应用生成器其他逆向工程设计恢复其他中央资源库项目管理工具（1）上游CASEA、用于系统规划的CASE

主要帮助系统分析员采集、存储、组织并分析业务模型。B、用于系统分析和设计的CASE

用于系统分析的图形工具主要有：UML、数据流程图DFD、数据字典DD、判定表、判定树、层次图HC、输入处理输出IPO等。常见工具：MicrosoftVisio、Sybase公司的PowerDesigner、IBM公司的RationalRose等。（2）下游CASEA、程序设计工具

Java开发工具Jbuilder、微软公司的VisualStudioB、测试工具

自动化测试工具Panorama、性能测试工具RationalQuantify3）项目管理CASE

MicrosoftProject项目管理软件、配置管理系统MicrosoftVisualSourceSafe(VSS)版本控制工具ConcurrentVersionsSystem(CVS)系统四、软件成熟度模型1、基本概念软件过程

人们用以开发和维护软件及其相关产品的一系列活动，包括软件工程活动和软件管理活动。软件过程能力

描述开发组织通过执行其软件过程能够实现预期结果的程度。软件过程性能

表示开发组织遵循其软件过程所得到的实际结果。软件过程成熟度

一个特定的软件过程被明确和有效地定义、管理、测量和控制的程度。软件能力成熟度等级

软件开发组织在走向成熟度的途中几个具有明确定义的、表征软件过程能力成熟度的平台。每一个等级包含一组过程目标，当其中一个目标被达到时，表明软件过程的一个重要方面得到实现，从而导致软件开发组织的软件过程能力进一步增长。关键过程域

相互关联的若干软件实践活动和有关基础设施的集合。关键实践

对关键过程域的实施起关键作用的方针、规程、措施、活动以及相关基础设施的建立、实施和检查。2、软件成熟度框架1）不成熟软件开发组织的问题软件过程没有一个明确、稳定的定义，由开发者和管理者在开发过程中临时拼凑。实施软件过程的管理方式是反应式的，即在遇到问题后才不得不作出反应。不能科学地制定进度和预算，在进度滞后时，往往以牺牲产品质量为代价。不存在判断产品质量，以及解决产品质量问题的软件过程。2）成熟的软件开发组织的特点具有全组织范围的控制软件开发和维护过程的能力对产品质量的分析和判断有客观、定量的依据。经理们时刻监控着软件产品的质量和顾客满意度。3）软件过程成熟度框架

是描述一条从无序的、混乱的过程达到成熟的、有纪律的过程的进化途径，把软件过程、软件过程能力、软件过程性能和软件过程成熟度等概念集为一体。3、软件能力成熟度模型1初始级2可重复级3已定义级4已管理级5优化级个别过程规范化过程标准且一致的过程可预见的过程持续的改进过程

软件能力成熟度模型描述了软件过程不断成熟的框架。模型把软件过程从无序到有序的进化过程分成几个阶段，将这些阶段排序，形成一个逐层提高的平台，使每个平台的过程能力为达到下一更高的平台打下基础。1）各成熟度等级的行为特征1初始级

组织的过程能力不可预测，软件过程经常被改变或修订。进度、预算、资源消耗和产品质量不可预测。性能依赖于个人的能力，且随个人具有的技能、知识和动机的不同而变化。2可重复级

软件项目的计划和跟踪是稳定的，并能重复以前的成功。3已定义级

该级别的过程能力可概括为已标准化的和一致的。无论软件工程活动还是管理活动，过程都是稳定的和可重复的。对成本、进度和功能实现均已受控制，软件质量可以跟踪。整个组织对项目定义的软件过程中的活动、角色和职责具有共同的和一致的理解。4已管理级

该级别的过程能力可概括为定量地可预测的。开发组织对软件产品和过程都设置了定量的质量目标，并经常对此进行测量和检查。通过将过程性能的变化限制在定量的可接受范围内，项目对其产品质量和过程进行仔细而严格的控制。5优化级

该级别的过程能力可概括为过程不断改进。开发组织不断改善组织内各项过程性能，既可通过在现有过程基础上增量式改进；也可采用新技术、新方法的革新办法，使软件过程不断得到改进。2）成熟度等级的内部结构成熟度等级关键过程域关键实践类关键实践过程能力目标有关职责和目的基础设施或活动包含指示达到组织成一些阐述描述包含若干

每个等级由几个关键过程域组成，这些关键过程域共同形成一种软件过程能力。因此，软件成熟度模型各个等级的设计，首先是确定关键过程域及其目标，然后详细设计和描述所有关键实践。初始级（1）可重复级（2）软件项目跟踪和监督软件需求管理软件计划管理软件配置管理软件质量保证软件子合同管理已定义级（3）可管理级（4）软件质量管理定量过程管理优化级（5）过程变更管理技术革新管理缺陷预防3）SEICMM1.1各等级的关键过程域同行评审组间协调软件产品工程集成软件管理培训大纲组织过程定义组织过程焦点软件外协管理软件版本管理基本软件工程一、UML的产生和发展1、UML及其起源及发展二、UML的基本概念1、什么是UMLUML是一种基于面向对象的可视化图形建模语言，用于对软件系统进行说明，构造和文档建立。1）UML中相互关联的含义UML合并了许多面向对象方法中被普遍接受的概念，并对每种概念给出了清晰的定义、表示法和有关术语。UML对于整个生命周期的开发具有无缝性。UML适用于各种应用领域的建模UML可应用于运行各种不同的编程语言和开发平台的系统。UML作为建模语言，不对开发过程的细节进行描述UML元模型揭示和表达了各种概念之间的内在联系。2）UML的目标提供一种所有建模人员都可使用的通用建模语言。能对众多系统建模的同时，尽可能简洁支持大部分软件开发过程使用面向对象概念为系统建模创建一种人和机器都可以使用的语言设计一种面向对象分析和设计的符号表示3）UML的特点统一标准面向对象可视化、表示能力强大独立于过程容易掌握使用4）UML概念模型UML事物关系图结构事物行为事物分组事物注释事物接口协作用例主动类构件节点交互状态机包注释依赖关联泛化类类图对象图用例图顺序图协作图状态图活动图构件图实施图事物是模型中最具有代表性的成分抽象。结构事物类：一组具有相同属性、相同操作、相同关系的对象的描述接口：描述一个类或构件的一个服务的操作集。协作：定义可一个交互。用例：是系统中的功能单元主动类：其对象至少拥有一个进程或线程，能够启动控制活动构件：系统中物理的、可替代的部件结点：系统运行时存在的物理单元行为事物交互：它由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。状态机：它描述一个对象或一个交互在生命期内响应时间所经历的状态序列分组事物包——把元素组成为组的机制关系依赖表示两个或多个模型元素之间的一种语义联系，其中一个事物的改变将影响另一个事物。关联通过一个事物可联想到另一个事物。泛化指模型要素之间的一般与特殊的联系。5）UML视图体系三、UML的视图和图1、视图

视图代表完整系统描述中一个特定方面的抽象，系统的整体架构和特征可以用一组视图完整地描述出来。每个视图由一组图构成。1）用例视图

用例视图从系统外部用户出发，抽象地描述系统的功能集合，使系统最终实现这个功能。用例视图是其他视图的核心和基础2）逻辑视图

逻辑视图显示系统内部的功能是怎样设计的，它利用系统的静态结构和动态行为来刻画系统功能。静态结构描述类、对象和它们之间的关系等；动态行为主要描述对象之间的动态协作。3）并发视图

并发视图用来显示系统并发工作的情况，主要由动态图（状态图、顺序图、协作图、活动图）和执行图（组件图、展开图）构成。为系统开发人员和集成人员使用。4）组件视图

组件视图用来显示代码组件的组织方式，描述实现模块和它们之间的依赖关系。组件视图由组件图构成，为开发者使用。5）展开视图

组件视图用来显示代码组件的组织方式，描述实现模块和它们之间的依赖关系。展开视图由展开图组成，包括结点和结点之间的关系。2、图

显示若干参与者以及参与者与系统提供的用例之间的连接关系1）用例图

图由图片组成，图片是模型元素的符号化。图是视图的组成部分，一个系统模型包括多个各种类型的图。鉴定保险单统计保险金额建立客户档案客户保险销售员1）用例概念的基本思路

首先找出系统边界以外的活动者，然后从活动者如何与系统进行对话的角度，以用例图描述活动者怎样使用系统以及系统向活动者提供什么功能。

例：客户对“下订单”用例的描述（场景）：“确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够”“活动者”—客户；系统对信息的处理—查找库存、检查客户信用额；处理之后的返回结果—客户订购的商品是否够，客户信用度是否够2）用例中的有关概念

系统边界：一个系统所包含的所有成分与系统以外的各种事物的分界线。活动者：是系统之外与系统进行交互的任何事物。

用例图是系统获取需求的重要手段，用例图反映系统的主要功能。2）类图

表示系统中类与类之间的关系，是对系统静态结构的描述。构造类图的三个关键问题：系统中有哪些需要关心的类？这些类是如何描述的？这些类之间的联系是什么？客户利润交易者生财工具债券股票选择股票1..*1..*0..*0..*113）对象图

对象图表示类的对象实例，具体反映该系统执行到某处时系统内事物的状态。（见图4—3）4）状态图

状态图对类所描述事物作补充说明，从而显示类的所有对象可能具有的状态，以及引起状态变化的事件。

例：对象“发票”可以根据其付款的情况分为3个状态：未付款、部分付款以及付清款未付款部分付款付清款部分付款部分付款完全付款

状态图使用状态、事件和转换来记录对象在其生命周期中所经历的状态序列。对象的初始状态是图中任何事件都未对该对象起作用时的状态状态代表对象生命周期中的某一瞬间转换表明作为对事件的响应结果，对象将从一种状态转换到另一种状态并执行某个动作。触发状态转换的事件在状态转换中命名。在一楼下降至一楼正在下降停止正在上升向上向下向上向上至要到达的楼层向下至要到达的楼层停止时间到向下至一楼开始计算机:打印服务器：.打印文件打印机：.队列结束打印打印文件加入队列通知打印打印文件打印机忙碌打印机空闲5）顺序图

表示随时间的推进，若干对象之间是如何交互作用的，显示对象之间的动态合作关系，强调对象之间消息发送的顺序。对象之间的这些交互是指在场景或用例的事件流中发生的。每一个对象用一条生命周期线来表示，在生命线上用棒形线表示该对象的服务按时间前进方向的执行动作，生命线之间的箭头连线代表消息。6）协作图

协作图按照时间和空间的顺序描述系统元素的交互和关系。协作图由对象及其关系，以及对象之间的流动消息构成。：计算机：打印服务器：队列：打印机1、打印文件4、打印结束2.1进入队列2.2离开队列3、打印文件7）活动图

任何一个系统任务在对象观点下对应于一系列有序的消息及消息的响应，但从系统的观点来看，它是一系列有序的活动，这些活动有序地通过事件的触发连接起来实现系统任务。尽管用例也从活动的角度描述系统，但用例的活动描述难以描述系统任务中的并发活动，以及跨用例的任务。因此，引入活动图主要目的是描述并发活动和跨用例的系统任务。活动图的核心概念是活动，活动是完成系统任务必需执行的处理步骤。在UML中活动本身是一种活动状态，与状态表示法完全相同。屏幕显示磁盘满屏幕显示打印产生附录文件檫除屏幕提示信息打印文件磁盘满磁盘有空闲8）组件图

组件图反映代码的物理结构。组件包含逻辑类的实现信息。窗口控件Whnd.obj主控模块Main.obj通信控件Comlind.obj客户程序Client.exe图形库Graphic.dll主控模块Main.cpp通信控件comlind.cpp窗口控件Whnd.cpp9）展开图

展开图又称配置图，显示系统中软件和硬件的物理架构，描述环境元素的配置，并把实现系统的元素映射到配置上。个人计算机个人计算机网络服务器数据库服务器客户系统.EXE客户系统.EXE网络服务.EXE查询系统.EXE网络TCP/IPTCP/IP开列订单验证客户<extend>用例图服务人员订单客户商品条目类图10）图例顺序图订单：……..客户：……..创建订单验证客户订单调出订单分发订单存档订单入座订单填写订单类的状态图创建订单确认订单提供优惠填写订单团体付费信用卡付费填写订单个别订户分支同步条团购订户同步条合并活动图——描述订单创建过程的活动3、图的模型元素和符号类（对象）属性操作状态用例结点笔记包组件接口模型元素符号关系符号聚合泛化关联依赖4、通用机制1）修饰

修饰是在模型元素旁边用附加的文字或规格说明。例如，在类型的名字下加下划线表示该类的实例（即对象）。2）笔记

笔记用于对模型的意义作进一步的解释3）规格说明

通用机制用于描述基本模型元素无法表达的附加信息

对模型元素性质的详细描述称为规格说明4）版类是UML提供的一种扩展机制，在已有模型的基础上建立一种新的模型元素5）约束约束是对元素的限制，通过约束限定元素的用法或元素的语义。四、用UML建模1、UML系统模型的组成分析模型设计模型实现模型展开模型系统模型从用户需求角度观察从数据库设计角度观察从物理实现角度观察从系统和网络构成角度观察类图状态图顺序图包图设计类图协作图用例图活动图对象数据库模式组件图展开图实施阶段设计阶段分析阶段事物事件或事件表2、UML建模的过程集体讨论描绘目标组织目标详细说明集成验证核实原型化与测试系统评价发现不足使用非正式工具，如白板或笔记公告把上面描绘的目标组织成正式的图反复迭代，明确内容，显示细节消除图形之间的冲突，保证系统正确有效完成原型并进行测试评价结果，必要时返回以纠正不足3、UML建模的工具支持（RationalRose)1）绘图支持

提供一致的图标和图片，可以选择、放置、连接和定义图中各元素。工具还具有理解元素的语义的能力，以及提供版面设计功能。2）模型积累图的一致性检索鉴定报告重用元素或图3）导航4）多用户支持一、系统分析概述1、系统分析的用户视图分析的目的：分析现实世界的事物如何转化到计算机世界，使信息系统能最终达到原来现实世界的目的。分析的结果：产生对现实世界一组准确、完整、一致并且可以检验的系统模型。系统拥有者系统用户系统设计者系统实施者关注数据关注处理关注接口关注通信系统开发商务知识数据需求数据库范式数据库程序系统分析员关注者系统分析与设计

方法学处理过程数据库管理系统销售与咨询商商务功能处理需求应用范式与说明商务地点接口需求通信环境通信需求系统分析阶段数据、功能和交互行为板块的用户视图2、模型驱动的分析方法

模型驱动的方法强调对现有系统和目标系统采用图示的系统模型来建立文档和提供验证手段。用例图：功能视图类图：数据视图状态图：功能视图顺序图：功能视图功能模型对象模型动态模型分析模型3、系统分析中使用的逻辑模型（1）事件和事件表

事件的相关要素：触发原因、消息来源、完成的动作、做出的响应、事件要达到的目的。（2）数据流（1）结构化分析要素

要传递的数据集合（3）数据流图（4）实体—关系图

表示系统逻辑功能和信息联系的一种图形.

表示系统要素之间关系的一种图形。（2）面向对象分析要素（1）类图

类图反映系统的静态结构，类的实例对象具有行为，行为是系统的动态特征，反映在特定的结构之下各组成部分的执行逻辑类的表示类名属性1属性2操作1（）操作n（）类的类型活动者类：代表出现在用例模型中的活动者业务类：描述业务的地点、物品、概念和事件用户界面类：是组成系统用户界面的屏幕显示、菜单和报表类的属性

属性是描述对象静态特征的一个数据项。属性有属性名和属性值。属性描述隐藏在对象内部的信息，由该对象的服务专门操作。类的服务（操作）

服务也称为方法或操作，是信息系统为满足用户需求必须采取的行动，是信息系统对事件的响应。服务的定义取决于具体问题域和功能需求，应遵循信息隐藏原理，执行单一的、高度内聚的功能。一个服务可以通过发送消息请求另一个服务的支持。类之间的联系泛化—特化聚合（整体—部分）关联消息传递泛化—特化联系

泛化—特化联系反映类之间的一种继承关系订单邮件订单电话订单网上订单聚合联系

也称整体—部分联系。反映各组成部分和整体之间的关系。计算机内存显示器CPU外存键盘111111111….*1….*关联联系

类之间的一种二元关系，表达对象之间的静态联系教师学生0….*1（2）用例图

用例图描述系统的环境和系统的功能需求。用例图中的关系用例图中的关系有活动者与用例之间的关系和用例与用例之间的关系。活动者与用例之间的关系称为关联，描述活动者与用例之间的关系用例之间的关系：包含关系、扩展关系、泛化关系关联：表示参与者与其参与执行的用例之间的通信路径扩展：在基础用例上插入基础用例不能说明的扩展部分<extend>包含：在基础用例之上插入附加行为，并具有明显描述<include>泛化：用例之间一般与特殊的关系，其中特殊用例(子用例）继承了一般用例（父用例）的特性，并增加了新的特性。包含的使用：如果两个以上的用例有大量一致的功能，可将该功能分解到另一个用例中；一个用例功能太多时，可以用包含关系建立两个小用例。包含与扩展的区别：在包含关系中一个用例总是在使用另一个用例的功能在扩展关系中，是根据某些条件有选择地使用另外一个用例功能。下订单查目录查询产品查供应商安排付款付现今付支票<extend><include><include><include>子用例父用例扩展用例客户（3）顺序图

显示场景或用例表中所发生的交互，它侧重于对消息时序的描述。（4）协作图

协作图强调对象之间的关系组织，而不是对象之间信息传递的时间性。协作图将消息名称前加上顺序号。（5）状态图

状态图用于描述具有复杂动态行为的对象，表示一个对象状态的演变。状态图的关键成分是状态和状态的转换闲置冷却激活预热过冷温度到达过热温度到达过冷加热准备/开关合上过热恒温器对象的状态图（6）活动图

表现于一组事件相连的多个对象的状态变化，强调在计算过程中顺序和并发的步骤带泳道的活动图请求服务取订单填写订单付款分发订单收集订单客户销售库房二、事件和事件的描述1、事件和系统需求

事件是指发生在确定的时间和地点，可以描述、并应该被系统记录下来的事实。系统分析首先应当考察对系统产生影响的外部事件。2、事件的类型（1）外部事件

由外部实体或动作参与者所引发的事件。外部事件将影响系统，触发系统内部进行一系列工作。识别外部事件的关键点：外部实体对系统的数据输入由外部实体的需要而触发的系统内部事务处理外部实体想要获取某些信息外部实体的变化引发系统内部数据需要更新（2）定时事件又称临时事件。是由于系统到达某一时刻系统内部自动发生的事件。时间事件是内部事件。（3）状态事件识别定时事件和状态事件的关键点：内部处理需要的临时输出结果；系统应当对外给出的结果；系统内部相关要素的状态依赖关系。是系统内部由于某个要素状态的改变而触发其他要素状态改变的事件。状态事件是内部事件。

。3、识别事件（1）准确区分事件、条件、响应和行为例：用电客户到银行交纳电费的例子。事件：用电客户交纳电费；条件：有信用卡；卡上有足够的钱；响应：银行从客户信用卡上划拨费用

如何区分事件与响应：判断两者能否分割开来。（2）列出事件的时间顺序通过跟踪事件处理的生命周期，列出事件的时间顺序。（3）技术选择和系统控制

技术实现和系统控制也将引发一系列事件，这类事件大多在系统设计阶段识别，但部分也需要在分析阶段识别。4、事件列表

事件列表中要包括：事件、触发器、来源、动作、响应、目的地，六大要素。触发器：事件与系统的接口。动作：事件消息传递给系统后，系统引发的一系列动作和行为。响应：系统对所发生事件的输出结果，可能是一个结果，也可能是一系列其他事件或动作。目的地：系统产生结果的送达地。可能是外部实体、参与者，或内部调用的其他系统。

例：“申办电子钱包”事件的事件列表三、事物、对象及其关系属性1、事物的类型

事物及其相关信息是系统要存储的数据。面向对象的分析中，事物是系统交互作用的对象。运用面向对象中，类与对象的抽象机制，寻找这些事物之间的内在关系。通过事件列表对事件的分析，来研判相应事件影响了哪些事物。事物实体事物边界事物控制事物实物角色地点位置组织交互行为时间2、对象之间的关系

对象之间发生的相互作用称为关系。对象之间的关系有一元关系、二元关系、多元关系。一元关系：同一类对象之间的关系。例：人与人、部门与部门之间的关系二元关系：不同类对象之间的关系。例：客户与信用卡之间的关系。多元关系：存在于3种或以上不同类对象之间的关系。（1）对象类之间关系的图示方法一对一的关系客户帐号电子钱包1…1

在每个对象类端点上都有一个重数1。一对多的关系在每个端点都有重数0….n，或*（表：1….n)。电子钱包银行1…*多对多的关系在一个端点上有一个重数1，另一个端点有重数0….n，或*（表：1….n)。客户银行*…《申办电子钱包》…*例：一个项目有许多活动组成；一个活动有许多任务组成；一个任务消耗若干资源，并产生若干工作成果；工作成果可以是：一个系统、一个模型、一个文档；资源可以是：参与者、时间或设备。用UML的图形元素可表示为：项目活动任务工作成果资源文档模型系统参与者时间设备*由……….生产消耗……….***（2）UML描述关系的四种主要结构依赖关系一个对象以某种方式影响另一个对象，后者并不一定受前者影响。聚集关系一个对象是由其部分之和构成的关系。关联关系表示一般事物和特殊事物之间的关系泛化关系系统中对象之间发生某种联系。3、对象的属性属性是对类（对象）特征的描述。系统分析关键是找出与类（对象）相关的属性。能唯一标示一个类（对象）的属性称为关键字。四、需求建模1、需求的概念面向对象的分析以用例模型描述系统的功能需求。软件工程对需求的定义

需求包括从用户角度和从系统开发者角度描述的用户为解决某个问题或实现某一目标，要求软件必须满足的条件或能力。功能需求

信息系统必须包括的功能和行为。功能需求主要表现在事件列表中。非功能需求

系统完成功能需求的能力。例如：过程方面、性能方面、外部特性方面等。约束条件

限制系统解决方案的可选范围的需求，如硬件、软件、人员组成等。信息系统用户需求约束条件功能需求非功能需求常规需求意外需求期望需求业务说明分析人员经验使用实例由…….产生由…….提示由…….产生2、需求描述的工具UML需求描述=事件表+类图+用例图+交互图（顺序图、协作图）+状态图（1）建立领域模型

建立领域模型是从事件表转化为类图的工作。领域对象是系统工作环境中存在的事情或发生的事件。领域中有如下三类对象：现实世界的对象：表示现实世界中要通过系统处理的事物，如货物、地点等；业务对象：表示业务中需要进行操作的事物，如订单、合同、帐户等；发生和将要发生的事件：表示能够引发系统工作或对系统产生影响的事实，如货物抵达、申请递交等。类图、对象图的建立步骤

确定对象和类。包括寻找、列举和删除对象和类找出对象之间的关系。包括聚类、泛化、关联等整理对象和类之间的关系。如删除、分解关联等。确认对象属性。根据领域知识找出属性和属性值。建立数据字典。对类图和对象图的内容列出必要说明。反复修正类图和对象图。例：从事件表到系统领域模型客户ID订单日期货号合同客户合同号付款方式个别客户电话付款方式商品条目商品代码目录期号商品目录目录期号有效期联系员工员工号1*1**1*0…1电话订货系统事件表：客户来电查询客户号查询商品目录开订单查询货物条目查询客户类别确定付款方式………..（2）建立业务模型

业务模型除包括类图、对象图以外，还要画出用例图、活动图、顺序图和状态图。

用例图从使用者角度描述系统。侧重从功能的角度描述业务过程的信息，表达业务过程各个功能的组成部分，确定参与者，以及参与者使用的业务用例。例：电话订货系统的用例图电话订货查询订单开列订单验证客户安排付款审核使用<extend><include><include><include><extend><extend>客户服务人员例：用例图、类图、顺序图、状态图之间的关系开列订单验证客户<extend>用例图服务人员服务人员订单客户商品条目类图顺序图订单：……..客户：……..创建订单验证客户订单调出订单分发订单存档订单入座订单填写订单类的状态图例：活动图—描述单个业务用例的细节过程创建订单确认订单提供优惠填写订单团体付费信用卡付费填写订单个别订户分支同步条团购订户同步条合并（3）需求说明的补充

对于非功能需求，采用传统手段进行说明。内容有：可用性：用户可以使用系统的时间百分比。可靠性：系统正确运行的可靠程度。性能：系统功能之外增加的条件。如，容量、响应时间、带宽等。可支持性：为保持可维护性、可扩展性必须达到的要求。设计约束：对系统设计的限制。接口需求：系统与外部的接口，如：软件接口、硬件接口、通信接口等。其他需求：在线帮助、产品许可等。

参与者（Actor)是UML的专门术语。特指系统外部介入系统的实体。可以是人员、设备、其他系统等。参与者的输入，或请求系统输出是触发系统用例执行的根源。区分实体、参与者、角色。同一实体在不同用例面前可能扮演不同角色。业务用例中的角色经系统分析员提炼成为参与者。3、功能分析（1）识别参与者

功能分析的工作：识别参与者、定义系统边界、识别系统用例、识别用例间的关系、建立用例模型，划分用例优先等级等。提炼角色为参与者的步骤：

考虑所有可能与系统运行有关的人员、设备和其他系统；确定系统在输入、输出方面的参与者；确定系统操作和维护方面的参与者；将参与者——用户——角色联系起来；进行合理组织和合并，减少功能重叠，形成参与者和角色类别；对参与者命名电话订货查询订单开列订单验证客户安排付款审核使用<extend><include><include><include><extend><extend>客户服务人员（2）定义系统边界大边框界定了系统边界（3）识别系统用例识别系统用例的两种方式：基于参与者的方式；基于事件的方式。整理用例集识别外部事件发现服务对象识别执行过程创建订单分析事件功能识别参与者通过系统必须响应的外部事件，找出系统的边界和内外联系通过系统功能分析，找出系统事件与参与者的关系，进而建立用例通过识别参与者，确认最终使用者和服务对象通过分析每个参与者所发起参加的执行过程，确定转化为用例的可能性通过对参与者、事件、过程、功能及相互关系的分析，建立用例和用例集合识别用例完成后，还要考虑以下问题：

每个参与者的特定任务是否完成？是否每个参与者都要从系统中创建、存储、改变、移动或读取信息？是否有特定任务或数据尚找不到参与者？是否需要将系统维护、支持的用例画上去？是否有其他重要的功能需求没有列上去？（4）识别用例间的关系

用例之间也有关系之间所具有的关系，即：关联、聚集、泛化等。用例之间还有两种特殊的关系：包含、扩展。包含关系：表示所触发用例的完成需要调用其他子用例。扩展关系：表示可以选择的行为集合、特定条件下才发生的行为集合、或者不同流程等。包含与扩展关系的区别：

描述的箭头方向：包含关系有主用例指向被包含用例；扩展关系由扩展用例指向主用例。逻辑关系：包含关系表示只要有就必须完成的功能；扩展关系表示一种可能的需要。验证身份核对IC卡核对密码电话订货查询订单开列订单验证客户安排付款审核使用<extend><include><include><include><extend><extend>客户服务人员（5）建立用例模型

使用用例图描述系统的一组用例、用例参与者、用例之间的关系和用例与参与者之间的关系。（6）划分用例的优先级

自上而下找出对系统最为重要的用例。并按以下原则对用例排序：以用例对系统商务模式的影响排序；以用例对商务模式的核心流程的影响排序；在每个级别内按功能实现的重要性排序；找出通用或实现简单的用例。五、需求建模实例1、学校教学管理系统需求建模

系统用户是：教学管理人员、教师、学生；系统功能：提供学生选修课程和学生成绩管理方面的服务。（1）系统需求

学生选课管理：包括，新学期选修课程表生成、学生选课注册、选修课查询、信息统计与报表生成、相关信息传递到财务管理系统。学生成绩管理：学生考试成绩录入、成绩查询、成绩汇总与报表生成。（2）确定系统范围和系统边界

教学管理系统的业务范围：只进行学生选课和考试成绩管理，不包括其他教学管理；系统边界：本教学管理系统与学校教务管理系统和财务管理系统有系统边界。教务管理系统只接受本系统汇总信息，不反馈；财务系统接受相关信息，并反馈学生交费信息。（3）参与者

学生教师教学管理人员教务管理系统财务管理系统（4）确定用例

“选修课管理”中的用例有：选修课程管理、选修课查询、选修课注册、教师简历查询、选修课统计汇总。“学生成绩管理”中的用例有：学生成绩管理、学生成绩查询、学生成绩统计汇总、（5）分层用例绘制选修课管理学生成绩管理教学管理员教师教务系统学生财务系统教学管理系统教务系统学生成绩管理子系统课程成绩查询学生成绩管理教学管理员教师学生财务系统学生成绩汇总学生成绩查询选修课注册选修课管理教学管理员教师学生财务系统选修课信息汇总选修课查询选修课管理子系统教师简历查询（6）用例汇总选修课管理学生成绩管理教学管理员教师教务系统学生财务系统课程成绩查询学生成绩管理学生成绩汇总学生成绩查询选修课注册选修课管理选修课信息汇总选修课查询教师简历查询（7）用例之间的关系选修课查询教师学生身份验证课程成绩查询选修课注册学生成绩查询<include><include><include><include>（8）建立对象类主要的类如下：学生教师教学管理人员选修课表选课单课程成绩（9）定义类之间的关系，建立类图学生1教师教学管理人员选修课表选课单课程成绩*11**1*****2、定单处理系统的用例模型（1）系统包含的参与者

电话代理信用授权机构产品仓库系统货运系统（2）系统与各类参与者的交互系统与电话代理的交互

输入定单取消定单取消定单明细查询系统与信用授权机构的交互

确认购买(系统告诉信用机构通过信用卡和借记卡购买)贷款帐户(系统告诉信用机构记录帐户)系统与产品仓库的交互

请求发货取消发货请求退货处理查询库存接受订货系统与货运系统的交互

运送货物退回定单物品输入定单查询取消定单明细取消定单电话代理贷款帐户确认购买信用授权机构退货处理接受定单取消发货请求查询库存请求发货产品仓库系统退回定单物品运送货物货运系统一、系统建模简介1、系统建模的概念信息系统是由一系列模型构成的有序集合。信息系统的开发方法是模型在不同层次上的建立方法。模型是现实世界中某些重要方面的抽象展示。每种模型强调一种不同类型的信息。模型可有多种表现形式信息系统分析人员用模型来模拟系统的流程、结构、功能等；从处理角度看，有：输入/输出模型、功能模型、数据模型、控制模型、决策模型等；从设计角度看，有动态模型、静态模型等。2、系统逻辑模型和物理模型系统分析阶段建立的需求模型，就是系统的逻辑模型。逻辑模型重点在于解决系统要“做什么”。逻辑模型显示系统在功能方面的总体要求。逻辑模型独立于具体实现技术。逻辑模型的“逻辑”特指业务处理中的数据内容和处理过程。逻辑模型物理模型重点解决系统“如何做”问题。与具体实现技术有关，并受限于技术条件（约束条件）完成技术设计方面的工作。逻辑模型与物理模型的区别逻辑模型的作用消除对技术细节的关注，聚焦于要解决的问题。便于人们准确、完整地把握要做的事情。便于系统分析人员与用户的沟通。是系统分析阶段的成果，是创建物理模型的依据。3、数据模型的概念数据模型是把系统数据有效组织起来形成文本化的一种技术。数据建模就是数据库