构建分析模型(1).pptVIP

构建分析模型 构建分析模型 在技术层面上，软件工程开始于一系列的建模工作，最终生成待开发软件的需求规格说明和全面的设计表示。分析模型实际上是一组模型是系统的第一个技术表示。 需求分析 需求分析产生软件操作特征的规格说明，指明软件和其他系统元素的接口，建立软件必须满足的约束。需求分析让软件工程师（有时这个角色也被称作分析师或建模师）细化在前期需求工程工作中建立的基础需求，并建立模型描述用户场景、功能活动、问题类和类之间的关系、系统和类行为以及数据流。 需求分析向软件设计者提供信息、功能和行为的表示，这些表示可以被转化为结构、接口和构件级的设计。最终，在软件完成后，分析模型和需求规格说明就为开发人员和客户提供了评估软件质量的手段。 在整个分析建模过程中，软件工程师的主要关注点集中在“做什么”而不是“怎么做”方面．包括：系统处理什么对象？系统必须执行什么功能？系统显示什么行为？定义什么接口？有什么约束？ 整体目标和原理 分析模型必须实现三个主要目标：（1)描述客户需要什么；（2)为软件设计奠定基础；（3）定义在软件完成后可以被确认的一组需求。分析模型在系统级描述（说明系统在软件、硬件、数据、人员和其他系统元素发挥作用后应达到的整体功能）和软件设计（说明软件的应用程序结构、用户接口、构件级的结构）的差距之间建立桥梁。 域分析 分析建模的方法 一种考虑数据和处理的分析建模方法被称作结构化分析，其中数据作为独立实体转换。数据对象建模定义了对象的属性和关系，操作数据对象的处理建模应表明当数据对象在系统内流动时处理如何转换数据。 分析建模的方法 分析建模的第二种方法称作面向对象的分析，这种方法关注于定义类和影响客户需求的。类之间的协作方式。UML和统一过程主要是面向对象的。 不要认为因为有域分析师在工作，软件工程师就不需要理解应用的领域。软件团队的每个成员都应该对软件将要使用的领域有一定的了解。 数据建模概念 分析建模通常开始于数据建模。软件工程师或分析师需要定义在系统内处理的所有数据对象、数据对象之间的关系以及其他与这些关系相关的信息。 数据对象 数据对象是几乎任何必须被软件理解的复合信息的表示。复合信息是指具有若干不同的特征或属性的事物。因此，“宽度”（单个的值）不是有效的数据对象，但是“维度”（包括宽度、高度和深度）可以被定义为一个对象。 数据属性 数据属性定义了数据对象的性质，可以具有三种不同的特性之一。它们可以用来：（1）为数据对象的实例命名；（2）描述这个实例；（3）建立对另一个表中的另一个实例的引用。 关系 数据对象可以以多种不同的方式互相连接。考虑两个数据对象：person和car。在person和car之间可以建立联系，因为这两个对象之间是相关的。但这个关系是什么呢？为确定答案，我们必须理解在将要构建的软件的环境中人（在这里是指车主）和车的角色。 基数和形态 数据建模的基本元素—数据对象、属性和关系—为理解问题的信息域提供了基础。然而，还必须理解与这些基本元素相关的其他元素。 我们已经定义了一组对象并表示了与之绑定的对象／关系对。但是，就软件工程的目的而言，简单地说对象X与对象冲关并没有提供足够的信息。我们必须理解对象X的多少次出现和对象Y的多少次出现相关，这引出了被称为基数的数据建模概念。 面向对象的分析 面向对象的分析（OOA），其目的是定义与即将解决的问题相关的所有类（以及与其相关的关系和行为）。为实现这一点，必须完成如下一些工作： 1.在客户和软件工程师之间必须对基本的用户需求进行交流。 2.必须确定类（也就是说，定义属性和方法）。 3.定义类的层次结构。 4.表现对象与对象的关系（对象连接）。 5.必须为对象行为建模。 6.上述1一5的工作步骤重复迭代直至模型完成。 基于场景建模 尽管可以用多种方式度量基于计算机的系统或产品，用户的满意度仍是其中最重要的。如果软件工程师了解最终用户（和其他参与者）希望如何与系统交互，软件团队将能够更好地、更准确地刻画系统特征，完成更有针对性的分析和设计模型。因此，使用UML分析建模，将从开发用例、活动图和泳道图形式的场景开始。 编写用例 用例捕获信息的产生者、使用者和系统本身之间发生的交互。—从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。 但是我们如何知道：（1）编写什么？（2）写多少？（3）编写说明应该多详细？（4）如何组织说明？如果想让用例像一个分析建模工具那样提供价值，那么必须回答这些问题。。 在很多情况下，不需要创建使用场景的图形化表示。然而，图形化的表示可以促进理解，尤其是当场景比较复杂时。正如我们提到的，UML的确为用例提供了图形化表现的能力。 开发活动图 UML活动图通过提供特定场景内交互流的图形化表示来补充用例