软件工程讲义_第07章 构建分析模型
构建模型教案
构建模型教案教案名称：构建模型教学目标：1. 理解什么是构建模型，并能够解释模型的重要性和应用领域。
2. 学习构建模型的步骤以及与实际问题的联系。
3. 能够运用构建模型的方法解决实际问题，并进行模型的评估和改进。
教学内容：一、引入构建模型作为数学建模的重要手段之一，广泛应用于各个学科领域。
例如在物理学中，通过构建模型可以研究物体的运动规律；在经济学中，构建经济模型可以分析经济变量之间的关系等。
本节课将引导学生了解构建模型的概念和应用场景。
二、概念解释与示例1. 什么是构建模型构建模型是指通过建立数学模型的方式来描述和解释实际问题。
模型是对真实世界的简化和抽象，它可以反映问题的本质和关键因素，并进行定量分析和预测。
例如，在城市交通规划中，可以通过构建交通流模型来评估不同方案的交通拥堵情况。
2. 构建模型的步骤(1) 确定问题和目标：明确需要解决的问题，并制定明确的目标。
(2) 收集数据：收集与问题相关的数据，并进行整理和清理。
(3) 建立假设：根据问题和数据，建立与问题相关的假设。
(4) 建立数学模型：根据问题和假设，选择适当的数学方法和工具，建立数学模型。
(5) 模型求解：运用数学方法和工具，对模型进行求解，得出问题的解答。
(6) 模型评估与改进：对模型进行评估，分析模型的优缺点，并对模型进行改进。
三、案例分析1. 案例一：物体的自由落体(1) 问题描述：一颗物体从高处自由落下，求物体的落地时间和落地速度。
(2) 假设：假设物体仅受重力作用。
(3) 数学模型建立：根据运动学方程，建立物体的自由落体模型。
(4) 模型求解：对模型进行求解，得出物体的落地时间和落地速度。
(5) 模型评估与改进：评估模型的准确性，并分析模型中的假设条件是否合理。
2. 案例二：经济增长模型(1) 问题描述：研究一个国家的经济增长情况，并预测未来的经济走势。
(2) 假设：假设经济增长率与人均GDP、人口增长率等因素相关。
(3) 数学模型建立：根据经济学理论和实际数据，建立经济增长模型。
第9课软件工程基础知识
7.4、系统设计知识
耦合是软件结构中各个模块之间相互关联程度的度量。 非直接耦合：如果两个模块没有没有直接关系，它们之间的联系完全是 通过主程序的控制和调用来实现的。 数据耦合：如果两个模块借助于参数表传递简单数据。 标志耦合：如果两个以上的模块都需要其余某一数据结构子结构时，不 使用全局变量的方式而是用记录传递的方式 控制耦合：如果一模块明显地把开关量、名字等信息送入另一模块，控 制另一模块的功能。 外部耦合：当模块与软件以个的环境有关时就发生外部耦合。例如：输 入输出把一个模块与特定的设备、格式、通信协议耦合在一起。 公共耦合：多个模块引用一全局数据区的模式。例如C语言中的external 数据类型、磁盘文件等都是全局数据区。 内容耦合：一个模块访问另一模块的内部数据；一个模块不通过正常入 口转到另一模块内部；两个模块有部分程序代码重叠；一个模块有多个 入口；
7.4、系统设计知识
内聚是一模块内部各个元素彼此结合的紧密程度的度量 偶然内聚：如果一个模块完成一组任务，这组任务彼此间即使有关系， 其关系也是松散的。 逻辑内聚：把几种逻辑上相关的功能组合在一起，每次被调用时，由传 送给的模块参数来确定该模块应完成哪一种功能。 时间内聚：如果一个模块所包含的任务必须在同一时间间隔内执行，这 个模块属于时间内聚，例如初始化模块。 过程内聚：如果一个模块的处理元素是相关的，而且必须按特定的次序 执行。 通信内聚：如果一个模块的所有功能都通过使用公用数据而发生关系。 顺序内聚：如果一个模块的处理元素是相关的，而且必须顺序执行，通 常一个处理元素的输出数据作为下一下处理元素的输入数据。 功能内聚：如果一个模块包括且仅包括为完成某一具体任务所必须的所 有成份，或者说模块中所有成分结合起来是为了完成一个具体的任务。
软件工程功能分析与概念模型
同步条
同步条：表示引入的信息流同时到达， 引出的信息流被同时触发
初始化
显示
测量
信息流、数据流、信号流
信息流：连接各活动并表示活动间的控制转移
数据流：连接活动与其I／O对象 信号流：连接收发信号与对象
泳道
泳道进一步描述完成活动的对象，并聚合一组活动。活动图是 另一种描述交互的方式，描述采取何种动作，做什么（对象状态 改变），何时发生（动作序列），以及在何处发生（泳道）。 泳道也是一种分组机制。 顾 客 售 货 库 房
适应; 可用泳道技术对同层活动进行活动状态与轨迹分组;
建模要点
活动图对功能分解层次的覆盖关系 ① 活动分割关系：子功能—活动 子功能—活动—动作 ② 每个底层用例可展开为一张活动图 （由单个用例中的相关活动序列组成） ③ 单个活动：由不可再分的相关动作序列组成
用例的活动图表示
1.2.4 常见问题分析
若一个用例中有完全不同的事件流最好把它分解成不同的用例常见问题审查与分析用例表示活动操作或状态用例表示活动操作或状态会员输入用户名验证用户名和密码会员登录include常见问题审查与分析用例表示系统活动用例表示系统活动查询订单建立数据库连接执行sql语句includeinclude常见问题审查与分析用例表示数据的增删改查用例表示数据的增删改查删除用户修改用户增加用户管理员查询用户常见问题审查与分析管理员用户管理管理员用户管理增加用户extend12活动图121活动图的作用122活动图基本概念123活动图建模过程124常见问题分析121活动图的作用活动模型用活动图表示活动模型用活动图表示一种观点认为活动图是一种特殊的状态图一种观点认为活动图是一种特殊的状态图活动图
软件工程模型方法
软件工程模型方法软件工程模型方法软件工程模型是指将软件开发过程中的各个阶段和活动组织起来的一种方法。
它提供了一种规划、管理和控制软件开发的方式，可以帮助团队更加高效地开发软件。
本文将介绍常见的软件工程模型方法，并对每个模型进行细化说明。
1、瀑布模型（Waterfall Model）瀑布模型是软件开发过程中最古老、最经典的模型之一。
它将软件开发过程划分为一系列连续的阶段，如需求分析、设计、编码、测试和维护等。
每个阶段都是线性顺序进行，前一个阶段的结果作为后一个阶段的输入。
这种模型适用于需求稳定、项目时间紧迫的情况。
2、原型模型（Prototype Model）原型模型是通过快速构建原型来确定用户需求的模型。
它首先开发一个初始的简单原型，与用户进行交互，获取反馈意见，然后不断迭代和改进原型，直到满足用户的需求。
原型模型适用于用户需求不明确或需要快速验证想法的情况。
3、增量模型（Incremental Model）增量模型将软件开发过程划分为多个独立的模块，每个模块都是一个完整的、可测试的子系统。
团队先开发核心功能的模块，然后逐步添加新功能，每个增量都经过测试和验证。
这种模型适用于大型项目和需求变化频繁的情况。
4、螺旋模型（Spiral Model）螺旋模型将软件开发过程分为多个迭代周期，每个周期包含风险分析、计划、开发和评估等活动。
团队在每个周期内通过风险评估来决定下一步的工作。
螺旋模型适用于复杂、大规模软件开发项目。
5、敏捷模型（Agile Model）敏捷模型是一种迭代、增量的开发方法，强调团队协作、灵活响应需求变化和频繁交付可工作软件。
常见的敏捷方法包括Scrum、XP和Kanban等。
敏捷模型适用于快速响应市场需求、团队需要灵活合作的情况。
6、DevOps模型DevOps模型是将开发（Development）和运维（Operations）整合在一起的一种方法。
团队通过自动化流程、持续集成和交付等实践，实现软件开发和运维的高效协作。
软件工程课本讲解第7章增量模型(精)
第7章 增量模型
图7.3 (a) 原型；(b) 原型的使用；(c) 开发过程
第7章 增量模型
在图7.3(c)中，实线箭头连接的表示探索型快速原型 模型的开发过程，双线箭头连接的表示实验型快速原型模 型的开发过程，虚线箭头连接的表示演化型快速原型模型 的开发过程。
对于探索型，用原型过程来代替需求分析，把原型作 为需求说明的补充形式，运用原型尽可能使需求说明完整、 一致、准确和无二义性，但在整体上仍采用瀑布模型。
第7章 增量模型
7.2 渐增模型
7.2.1 增量构造模型 增量构造模型如图7.1所示。在该模型中，需求分
析阶段和设计阶段都是按瀑布模型的整体方式开发的， 但是编码阶段和测试阶段是按增量方式开发的。在这 种模型的开发中，用户可以及早看到部分软件功能， 及早发现问题，以便在开发其他软件功能时及时解决 问题。
第7章 增量模型
增量模型和瀑布模型之间的本质区别是：瀑布模型 属于整体开发模型，它规定在开始下一个阶段的工作之 前，必须完成前一阶段的所有细节。而增量模型属于非 整体开发模型，它推迟某些阶段或所有阶段中的细节， 从而较早地产生工作软件。
增量模型是在项目的开发过程中以一系列的增量方 式开发系统。增量方式包括增量开发和增量提交。增量 开发是指在项目开发周期内，以一定的时间间隔开发部 分工作软件；增量提交是指在项目开发周期内，以一定 的时间间隔增量方式向用户提交工作软件及相应文档。 增量开发和增量提交可以同时使用，也可单独使用。
第7章 增量模型
2. 需求是模糊的
对于某些类型的软件系统，如操作系统、编译系统等系统软 件，人们对它们比较熟悉，有长期使用它们的经验，其需求经过 仔细的分析之后可以预先指定。但是，对于大多数经常使用的应 用系统，例如管理信息系统，其需求往往很难预先准确的指定， 也就是说，预先定义需求的策略所做出的假设，只对某些软件成 立，对多数软件并不成立。许多用户对他们的需求最初只有模糊 的概念，想要求一个对需求只有初步设想的人准确无误地说出全 部需求，显然是不切实际的。人们为了充实和细化他们的初步设 想，通常需要经过在某个能运行的系统上进行实践的过程。
模型构建法基础知识点总结
模型构建法基础知识点总结本文将从模型构建的基本流程、常用的模型类型、模型评估以及一些常用的模型构建工具等方面展开介绍，希望能为初学者提供一些帮助。
一、模型构建的基本流程模型构建的基本流程一般包括数据收集、数据清洗和预处理、特征工程、模型选择和训练、模型评估等步骤。
下面将对每个步骤进行具体介绍。
1. 数据收集数据收集是模型构建的第一步，它涉及到从各种数据源中获取数据。
常见的数据源包括数据库、文本文件、网络数据等。
在数据收集过程中需要注意数据的完整性和准确性，以确保后续模型构建的质量。
2. 数据清洗和预处理数据清洗和预处理是模型构建的重要环节。
在这个阶段需要处理缺失值、异常值、重复值等问题，同时还需要对数据进行标准化、归一化、转换等处理。
这些工作能够提高数据的质量，减少模型构建的干扰。
3. 特征工程特征工程是模型构建的关键环节，它涉及到从原始数据中提取和选择最能代表现象或者对预测目标有帮助的特征。
常见的特征工程包括特征选择、特征变换、特征组合等。
4. 模型选择和训练模型选择和训练是模型构建的核心环节。
在这一阶段需要根据业务需求选择合适的模型类型，然后使用训练数据对模型进行训练。
常见的模型类型包括线性模型、决策树、神经网络、支持向量机等。
5. 模型评估模型评估是模型构建的最后一步，它涉及到使用测试数据对训练好的模型进行评估。
常见的评估指标包括准确率、精确率、召回率、F1值等。
二、常用的模型类型在模型构建中，常见的模型类型包括线性回归模型、逻辑回归模型、决策树模型、随机森林模型、支持向量机模型、神经网络模型等。
下面将对每种模型类型进行具体介绍。
1. 线性回归模型线性回归模型是一种用来描述自变量和因变量之间线性关系的模型。
它的表达式为y =w1*x1 + w2*x2 + ... + wn*xn + b，其中w1, w2, ..., wn和b是模型参数。
2. 逻辑回归模型逻辑回归模型是一种用来描述分类问题的模型。
第七章 软件能力成熟度模型
排1.5年到2年）。 ? 根据CMU-SEI的统计，软件企业在引入 CMM
后劳动生产率平均增长了 35%；错误比率平均 减少39%；平均成本回报率为 5：1。
本章内容提要
? 软件过程与过程管理 ? CMMI概述 ? CMMI的成熟度等级及其过程域 ? CMMI的应用 ? PSP，TSP与CMMI
等级5：优化 组织革新与部署
管理级
原因分析与解决
缩写词 ISM OEI IT OPP QPM
OID CAR
5.CMMI的能力等级
? 能力等级 （Capability Level, CL ）是指在一 个单独的过程域中执行的良好程度。
? CMMI包括6个能力等级： ?CL0 ，不完整级：过程域的一个或多个目标 没有被满足。 ?CL1 ，已执行级：过程通过转换可识别的输 入工作产品，产生可识别的输出工作产品。 能实现过程域的特定目标。
成熟度等级
关键过程域
等级2：已 需求管理
管理级
项目计划
项目监督与控制
供应商协议管理
度量和分析
过程和产品质量保证
配置管理
等级3：已 需求开发
定义级
技术解决方案
缩写词 REQM PP PMC SAM MA PPQA CM RD TS
4.CMMI的关键过程域(续）
成熟度等级
关键过程域
等级3：已 产品集成
1.CMMI的历史（续）
?IPD-CMM (Integrated systems product Development CMM): 集成系统产品开发 CMM，应用于集成系统产品的开发管理。
软件工程模型方法
软件工程模型方法软件工程模型方法1.概述软件工程是一门关注软件开发的学科，而软件工程模型方法则是指在软件开发过程中，用于规划、管理和控制软件开发活动的一系列方法和模型。
软件工程模型方法可以帮助开发团队高效地组织工作，减少开发过程中的风险，并最终交付高质量的软件产品。
在本文中，我们将介绍几种常见的软件工程模型方法，包括瀑布模型、原型模型、增量模型和敏捷模型。
通过了解这些模型方法的特点和适用场景，开发团队可以根据项目的具体需求选择最合适的模型方法，提升软件开发的效率和质量。
2.瀑布模型瀑布模型是一种顺序性的软件开发模型，包括需求分析、系统设计、编码、测试和发布等阶段，每个阶段的输出作为下一个阶段的输入。
瀑布模型适用于需求稳定、项目周期长且工作流程明确的项目，适合大规模软件开发。
该模型的优势在于清晰的阶段划分和任务分工，开发人员可以按照固定的流程推进开发工作，便于管理和控制。
然而，瀑布模型存在风险，一旦前期需求分析和设计出现问题，后续阶段的工作将受到严重影响。
3.原型模型原型模型是一种通过快速构建原型来获取用户反馈的软件开发模型。
在该模型中，开发团队通过构建一个简化的原型系统来验证功能和用户界面设计，根据用户反馈进行迭代调整，达到用户满意的目标。
原型模型适用于需求不确定、创新性强和用户参与度高的项目。
它可以帮助开发团队更好地理解和满足用户需求，减少开发中的风险。
然而，原型模型需要耗费较多的时间和资源来构建原型系统，同时需要与用户进行密切的合作和交流。
4.增量模型增量模型是一种逐渐构建系统的软件开发模型，将软件系统划分为多个独立的模块，每个模块按照优先级顺序逐步开发和集成。
增量模型适用于需求变化频繁或紧迫，项目周期较短的项目。
该模型的优势在于快速交付可用系统，并且可以在项目进行过程中不断调整需求和优化模块。
同时，增量模型可以提高开发团队的反馈速度和用户满意度。
然而，增量模型也存在一些挑战，如模块集成的复杂性和需求变化带来的项目管理困难。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据对象
数据对象只封装数据——在数据对象内没 有对作用于数据的操作的引用。数据可以 表示为如图7-4所示的一张表，表头反映 了对象的属性。表体表示了数据对象的特 定实例。
数据对象的表格表示
图7-4 数据对象的表格表示
数据属性
数据属性定义了数据对象的性质，可以具 有三种不同的特性之一。它们可以用来：
SafeHome系统的初步用例图
图7-6 SafeHome系统的初步用例图
开发活动图
UML活动图通过提供特定场景内交互流的 图形化表示来补充用例。活动图使用圆角 矩形表示一个特定的系统功能，箭头表示 通过系统的流，判定菱形表示判定分支， 水平线意味着并行发生的活动。ACS-DCV 功能的活动图如图7-7所示。
SafeHome实例[14]
编写用例
这个连续的陈述没有考虑其他可能的交互。这种 类型的用例有时被称作主场景。 要完整地理解所描述的功能，必需说明可能的交 互。主场景中的每个步骤将通过如下提问得到评 估：
在这一点，参与者能进行一些其他活动吗？ 在这一点，参与者有没有可能遇到一些错误的情况？ 在这一点，参与者有没有可能遇到一些其他的行为？ 如果有，是什么？
基于场景建模
如果软件工程师了解最终用户（和其他参 与者）希望如何与系统交互，软件团队将 能够更好地、更准确地刻画系统特征，完 成更有针对性的分析和设计模型。使用 UML分析建模，将从开发用例、活动图和 泳道图形式的场景开始。
编写用例
用例捕获信息的产生者、使用者和系统本 身之间发生的交互。 用例从某个特定参与者的角度用简单易懂 的语言说明一个特定的使用场景。但是我 们应该知道：(1)编写什么？(2)写多少？ (3)编写说明应该多详细？(4)如何组织说 明？
SafeHome系统ACS-DCV功能的泳道图
图7-8 ACS-DCV功能的泳道图
面向流的建模
面向流的数据建模至今仍是最广泛使用的分析表 达法之一。尽管数据流图及相关的图和信息不是 UML的正式组成部分，但是它们可以补充UML图 并提供对系统需求和流的补充认识。 DFD采取了系统的输入-处理-输出观点。流入软 件的数据对象，经由处理元素转换，最后以结果 数据对象的形式流出软件。数据对象由带标记的 箭头表示，转换由圆圈（也称作泡泡）表示。 DFD使用分层的方式表示，即第一个数据流模型 从整体上表现系统，随后的数据流图改进环境图， 提供每个后续层增加的细节。
编写用例
两个首要的需求工程工作——起始和导 出——提供了开始编写用例所需要的信息。 运用需求收集会议、QFD和其他需求工程 机制确定共利益者，定义问题的范围，说 明整体的操作目标，概述所有已知的功能 需求，描述系统将处理的信息（对象）。 要开始开发用例，应列出特定参与者执行 的功能或活动。这些可以从所需系统功能 的列表中获得，或通过与客户或最终用户 交流获得，或通过评估活动图获得。
分析模型的元素
图7-3 分析模型的元素
数据建模概念
分析建模通常开始于数据建模。软件工程 师或分析师需要定义在系统内处理的所有 数据对象、数据对象之间的关系以及其他 与这些关系相关的信息。
数据对象
数据对象是几乎任何必须被软件理解的复 合信息的表示。复合信息是指具有若干不 同的特征或属性的事物。 数据对象可能是外部实体、事物、发生或 事件、角色、组织单位、地点或结构。 “数据对象描述”包括了数据对象及其所 有属性。
分析模型在系统级描述和软件设计的差距之间 建立桥梁。 重要的是要注意到在系统描述中给出分析模型 的某些元素，并且需求工程的工作实际上是作为 系统工程的一部分开始的。此外，分析模型的所 有元素都可以直接跟踪到设计模型。通常难以区 分这两个重要的建模活动之间的设计和分析工作， 有些设计总是作为分析的一部分进行，而有些分 析将在设计中进行。
面向对象的分析
面向对象的分析(OOA)，其目的是定义与 即将解决的问题相关的所有类(以及与其相 关的关系和行为)。为实现这一点，必须完 成如下一些工作：
1、在客户和软件工程师之间必须对基本的用户需求进 行交流。 2、必须确定类（即定义属性和方法）。 3、定义类的层次结构。 4、表现对象与对象的关系（对象连接）。 5、必须为对象行为建模。 6、上述1-5的工作步骤重复迭代直至模型完成。
这些问题的答案导致创建一组次场景，次场景属 于原始用例的一部分，但是表现了可供选择的行 为。
SafeHome实例[15]
编写用例
在很多情况下，不需要创建使用场景的图 形化表示。但是图形化表示可以促进理解， 尤其是当场景比较复杂时。UML为用例提 供了图形化表现的能力。图7-6为 SafeHome系统的初步用例图。
面向对象的概念
属性——说明一个类的数值集合。 类——封装数据和过程的抽象，这些是说明某些 真实世界中的实体的内容和行为所必需的。即类 是一组相似对象的概括说明。 对象——某个特定类的实例。对象具有类的属性 和操作。 操作——也称为方法和服务，表现类的某个行为。 子类——超类的特化，子类可以从超类继承属性 和操作。 超类——也称作基类，是一组相关类的泛化。
SafeHome实例[12]
编写用例
随着和共利益者更多地交谈，需求收集团 队为每个标记的功能开发用例。通常，用 例首先用非正式的描述性风格编写。如果 需要更正式一些，可以使用类似前一章中 提出的某个结构化的形式重新编写同样的 用例。
SafeHome实例[13]
编写用例
描述性用例的一种变形是通过用户活动的 顺序序列表现交互，每个活动由声明性的 语句表示。
基数和形态
数据模型必须能够表示在一个给定的关系 中对象出现的次数。 基数是关于一个（对象）的出现次数可以 与另一个（对象）的出现次数相关联的规 格说明。 对于关系的出现，如果没有明确的必要性 或关系是可选的，那么关系的形态是0；如 果关系必须出现一次，那么形态是1。
数据建模
数据建模工具为软件工程师提供表现数据 对象、数据对象的特点和数据对象的关系 的能力。主要用于大型数据库应用系统和 其他信息系统项目，数据建模工具以自动 化的方式创建全面的实体—关系图、数据 对象字典以及相关模型。
现代软件工程
第7章 构建分析模型
主要内容
需求分析 分析建模的方法 数据建模概念 面向对象的分析 基于场景建模 面向流的建模 基于类的建模 生成行为模型 小结
分析模型
文字记录是极好的交流工具，但并不必然 是表达计算机软件需求的最好方式。分析 建模使用文字和图表的综合形式，以相对 容易理解的方式描绘需求的数据、功能和 行为，更重要的是，可以更直接地评审它 们的正确性、完整性和一致性。 软件工程师使用从客户那里提取的需求构 建模型。
分析建模的方法
软件团队往往选择一种方法并排斥另一种 方法中的所有表示手段。问题不是哪一种 方法最好，而是怎么组合这些表示手段才 能够为共利益者提供最好的软件需求模型 和过渡到软件设计的最有效方法。 分析模型将生成如图7-3所示的每个建模 元素的派生类。然而，不同项目之间，每 个元素的特定内容可能因项目而异。软件 团队必须想办法保持模型的简单性。只有 那些为模型增加价值的建模元素才能使用。
域分析
分析模型通常在特定业务领域内的很多应 用中重复发生。如果用一种方式对这些模 式加以定义和分类，让软件工程师或分析 师识别并复用这些模式，将促进分析模型 的创建。更重要的是，应用可复用的设计 模式和可执行的软件构件的可能性将显著 增加。
域分析
软件域分析是识别、分析和详细说明来自 某个特定应用领域的公共需求，特别是那 些在该应用领域内被多个项目重复使用 的……“面向对象的域分析”是在某个特 定应用领域内，根据通用的对象、类、部 件和框架、识别、分析和详细说明公共的、 可复用的能力。 域分析的目标很简单，就是：查找或创建 那些分析类和（或）能够广泛应用的、共 有的功能和特点，这样就可以复用。
SafeHome系统ACS-DCV功能的活动图
图7-7 ACS-DCV功能的活动图
泳道图
UML泳道图是活动图的一种有用的变形， 可让建模人员表示用例所描述的活动流， 同时指示哪个参与者或分析类对活动矩形 所描述的活动负责。职责由纵向分割图的 并列条形部分表示，就像游泳池中的泳道。 ACS-DCV功能的泳道图如图7-8所示。
需求分析
在整个分析建模过程中，软件工程师的主 要关注点集中在“做什么”而不是“怎么 做”方面。包括：系统处理什么对象？系 统必须执行什么功能？系统显示什么行为？ 定义什么接口？有什么约束？
整体目标和原理
分析模型必须实现三个主要目标：
描述客户需要什么； 为软件设计奠定基础； 定义在软件完成后可以被确认的一组需求。
分析模型
必须评审分析建模工作产品的正确性、 完整性和一致性，必须反映所有共利益者 的要求并建立一个可以从中导出设计的基 础。
分析模型
在技术层面上，软件工程开始于一系列的 建模工作，最终生成待开发软件的需求规 格说明和全面的设计表示。分析模型实际 上是一组模型，是系统的第一个技术表示。
分析阶段的目标[DEM79]
域分析的输入和输出
图7-2 域分析的输入和输出
分析建模的方法
一种考虑数据和处理的分析建模方法被称 作结构化分析，其中数据作为独立实体转 换。数据对象建模定义了对象的属性和关 系，操作数据对象的处理建模应表明当数 据对象在系统内流动时处理如何转换数据。 分析建模的第二种方法称作面向对象的分 析，这种方法关注于定义类和影响客户需 求的类之间的协作方式。UML和统一过程 主要是面向对象的。
分析模型
可以使用很多不同格式的图表为信息、功 能和行为需求建模。基于场景的建模从用 户的角度表现系统；面向流的建模在说明 数据对象如何通过处理函数进行转换方面 提供了指示；基于类的建模定义了对象、 属性和关系；行为建模描述了系统状态、 类和事件在这些类上的影响。一旦创建了 模型的雏形，就将不断改进，并分析评估 其清晰性、完整性和一致性。最终的分析 模型将由所有的共利益者确认。