《uml系统分析设计》读后感

时间：2017-09-18 20:18

uml的特点

Unified Modeling Language

UML的应用在哪方面

UML的应用领域 UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。

其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。

总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。

此外，UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。

在需求分析阶段，可以用用例来捕获用户需求。

通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。

分析阶段主要关心问题域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类以及它们相互间的关系，并用UML类图来描述。

为实现用例，类之间需要协作，这可以用UML动态模型来描述。

在分析阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯和并行性等问题的类）。

这些技术细节将在设计阶段引入，因此设计阶段为构造阶段提供更详细的规格说明。

编程（构造）是一个独立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。

在用UML建立分析和设计模型时，应尽量避免考虑把模型转换成某种特定的编程语言。

因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过早考虑编码问题十分不利于建立简单正确的模型。

UML模型还可作为测试阶段的依据。

系统通常需要经过单元测试、集成测试、系统测试和验收测试。

不同的测试小组使用不同的UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用部件图和合作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。

总之，标准建模语言UML适用于以面向对象技术来描述任何类型的系统，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。

在UML中，约束有哪两种表示方法
它们分别是什么

当然，步痕旅游网想法：您的查询字词都已标明如下：商务信息的具体定义 (点击查询词，可以跳到它在文中首次出现的位置) 如果打开速度慢，您可以尝试打开无图片的快照(百度和网页的作者无关，不对其内容负责。

百度快照谨为网络故障时之索引，不代表被搜索网站的即时页面。

UML的静态建模机制包括用例图(Use case diagram)、类图(Class diagram)、对象图(Object diagram )、包(Package)、构件图(Component diagram)和配置图(Deployment diagram)。

用例图用例模型(Use case model) 长期以来，在面向对象开发和传统的软件开发中，人们根据典型的使用情景来了解需求。

但是，这些使用情景是非正式的，虽然经常使用，却难以建立正式文挡。

用例模型由Ivar Jacobson在开发AXE系统中首先使用，并加入由他所倡导的OOSE和Objectory方法中。

用例方法引起了面向对象领域的极大关注。

自1994年Ivar Jacobson的著作出版后，面向对象领域已广泛接纳了用例这一概念，并认为它是第二代面向对象技术的标志。

用例模型描述的是外部执行者(Actor)所理解的系统功能。

用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。

首先，它描述了待开发系统的功能需求; 其次，它将系统看作黑盒，从外部执行者的角度来理解系统; 第三，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。

在UML中，一个用例模型由若干个用例图描述，用例图主要元素是用例和执行者。

用例(use case) 从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。

以字处理软件为例，“将某些正文置为黑体”和“创建一个索引”便是两个典型的用例。

在UML中，用例被定义成系统执行的一系列动作，动作执行的结果能被指定执行者察觉到。

在UML中，用例表示为一个椭圆。

图1显示了一个金融贸易系统的用例图。

其中，“风险分析”，“交易估价”，“进行交易”，“设置边界”，“超越边界的交易”，“评价贸易”，“更新帐目”等都是用例的实例。

概括地说，用例有以下特点: ·用例捕获某些用户可见的需求，实现一个具体的用户目标。

·用例由执行者激活，并提供确切的值给执行者。

·用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。

图1 金融贸易系统用例执行者(Actor) 执行者是指用户在系统中所扮演的角色。

其图形化的表示是一个小人。

图1中有四个执行者:贸易经理、营销人员、售货员和记帐系统。

在某些组织中很可能有许多营销人员,但就该系统而言,他们均起着同一种作用,扮演着相同的角色,所以用一个执行者表示。

一个用户也可以扮演多种角色(执行者)。

例如,一个高级营销人员既可以是贸易经理,也可以是普通的营销人员;一个营销人员也可以是售货员。

在处理执行者时,应考虑其作用,而不是人或工作名称,这一点是很重要的。

图1中,不带箭头的线段将执行者与用例连接到一起,表示两者之间交换信息,称之为通信联系。

执行者触发用例,并与用例进行信息交换。

单个执行者可与多个用例联系;反过来,一个用例可与多个执行者联系。

对同一个用例而言,不同执行者有着不同的作用:他们可以从用例中取值,也可以参与到用例中。

需要注意的是执行者在用例图中是用类似人的图形来表示,尽管执行的,但执行者未必是人。

例如,执行者也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。

在图1中,我们可以看到,记帐系统是一个外界系统,它需要更新帐目。

通过实践,我们发现执行者对提供用例是非常有用的。

面对一个大系统,要列出用例清单常常是十分困难。

这时可先列出执行者清单,再对每个执行者列出它的用例,问题就会变得容易很多。

使用和扩展(Use and Extend) 图1中除了包含执行者与用例之间的连接外,还有另外两种类型的连接,用以表示用例之间的使用和扩展关系。

使用和扩展是两种不同形式的继承关系。

当一个用例与另一个用例相似,但所做的动作多一些,就可以用到扩展关系。

例如图1中,基本的用例是进行交易。

交易中可能一切都进行得很顺利,但也可能存在扰乱顺利进行交易的因素。

其中之一便是超出某些边界值的情况。

例如,贸易组织会对某个特定客户规定最大贸易量,这时不能执行给定用例提供的常规动作,而要做些改动。

我们可在进行交易用例中做改动。

但是,这将把该用例与一大堆特殊的判断和逻辑混杂在一起,使正常的流程晦涩不堪。

图1中将常规的动作放在进行交易用例中,而将非常规的动作放置于超越边界的交易用例中,这便是扩展关系的实质。

当有一大块相似的动作存在于几个用例,又不想重复描述该动作时,就可以用到使用关系。

例如,现实中风险分析和交易估价都需要评价贸易,为此可单独定义一个用例,即评价贸易,而风险分析和交易估价用例将使用它。

请注意扩展与使用之间的相似点和不同点。

它们两个都意味着从几个用例中抽取那些公共的行为并放入一个单独用例中,而这个用例被其他几个用例使用或扩展。

但使用和扩展的目的是不同的。

用例模型的获取几乎在任何情况下都会使用用例。

用例用来获取需求,规划和控制项目。

用例的获取是需求分析阶段的主要任务之一,而且是首先要做的工作。

大部分用例将在项目的需求分析阶段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集中。

用例集中的每个用例都是一个潜在的需求。

1. 获取执行者获取用例首先要找出系统的执行者。

可以通过用户回答一些问题的答案来识别执行者。

以下问题可供参考: ·谁使用系统的主要功能(主要使用者)。

·谁需要系统支持他们的日常工作。

·谁来维护、管理使系统正常工作(辅助使用者)。

·系统需要操纵哪些硬件。

·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。

·对系统产生的结果感兴趣的人或事物。

相关回复解析UML的静态建模机制（2） 2. 获取用例一旦获取了执行者,就可以对每个执行者提出问题以获取用例。

以下问题可供参考: ·执行者要求系统提供哪些功能(执行者需要做什么)? ·执行者需要读、产生、删除、修改或存储的信息有哪些类型。

·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?怎样把这些事件表示成用例中的功能? ·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现? 还有一些不针对具体执行者问题(即针对整个系统的问题): ·系统需要何种输入输出?输入从何处来?输出到何处? ·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题? 需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知道执行者是什么。

一个用例必须至少与一个执行者关联。

还需要注意:不同的设计者对用例的利用程度也不同。

例如,Ivar Jacobson说,对一个十人年的项目,他需要二十个用例。

而在一个相同规模的项目中,Martin Fowler则用了一百多个用例。

我们认为:任何合适的用例都可使用,确定用例的过程是对获取的用例进行提炼和归纳的过程,对一个十人年的项目来说,二十个用例似乎太少,一百多个用例则嫌太多,需要保持二者间的相对均衡。

类图、对象图和包数千年以前,人类就已经开始采用分类的方法有效地简化复杂问题,帮助人们了解客观世界。

在面向对象建模技术中,我们使用同样的方法将客观世界的实体映射为对象,并归纳成一个个类。

类(Class)、对象(Object)和它们之间的关联是面向对象技术中最基本的元素。

对于一个想要描述的系统,其类模型和对象模型揭示了系统的结构。

在UML中,类和对象模型分别由类图和对象图表示。

类图技术是OO方法的核心。

图2显示了一个金融保险系统的类图。

图2 金融保险系统类图类图类图(Class Diagram)描述类和类之间的静态关系。

与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。

类图是定义其它图的基础。

在类图的基础上,状态图、合作图等进一步描述了系统其他方面的特性。

类和对象对象(Object)与我们对客观世界的理解相关。

我们通常用对象描述客观世界中某个具体的实体。

所谓类(Class)是对一类具有相同特征的对象的描述。

而对象是类的实例(Instance)。

建立类模型时,我们应尽量与应用领域的概念保持一致,以使模型更符合客观事实,易修改、易理解和易交流。

类描述一类对象的属性(Attribute)和行为(Behavior)。

在UML中,类的可视化表示为一个划分成三个格子的长方形(下面两个格子可省略)。

图1中,客户就是一个典型的类。

类的获取和命名最顶部的格子包含类的名字。

类的命名应尽量用应用领域中的术语,应明确、无歧义,以利于开发人员与用户之间的相互理解和交流。

类的获取是一个依赖于人的创造力的过程,必须与领域专家合作,对研究领域仔细地分析,抽象出领域中的概念,定义其含义及相互关系,分析出系统类,并用领域中的术语为类命名。

一般而言,类的名字是名词。

· 类的属性中间的格子包含类的属性,用以描述该类对象的共同特点。

该项可省略。

图2中“客户”类有客户名、地址等特性。

属性的选取应考虑以下因素: *原则上来说,类的属性应能描述并区分每个特定的对象; *只有系统感兴趣的特征才包含在类的属性中; *系统建模的目的也会影响到属性的选取。

根据图的详细程度,每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。

UML规定类的属性的语法为: 可见性属性名 : 类型 = 缺省值 {约束特性} 图2“客户”类中,客户名属性描述为- 客户名 : 字符串 = 缺省客户名。

可见性-表示它是私有数据成员,其属性名为客户名,类型为字符串类型,缺省值为缺省客户名,此处没有约束特性。

不同属性具有不同可见性。

常用的可见性有Public、Private和Protected三种,在UML中分别表示为、-和#。

类型表示该属性的种类。

它可以是基本数据类型,例如整数、实数、布尔型等,也可以是用户自定义的类型。

一般它由所涉及的程序设计语言确定。

约束特性则是用户对该属性性质一个约束的说明。

例如{只读}说明该属性是只读属性。

· 类的操作(Operation) 该项可省略。

操作用于修改、检索类的属性或执行某些动作。

操作通常也被称为功能,但是它们被约束在类的内部,只能作用到该类的对象上。

操作名、返回类型和参数表组成操作界面。

UML规定操作的语法为: 可见性操作名 (参数表) : 返回类型 {约束特性} 在图2中,客户类中有取客户地址操作,其中表示该操作是公有操作,调用时需要参数客户名,参数类型为字符串,返回类型也为字符串。

类图描述了类和类之间的静态关系。

定义了类之后,就可以定义类之间的各种关系了。

关联关系关联(Association)表示两个类之间存在某种语义上的联系。

例如,一个人为一家公司工作,一家公司有许多办公室。

我们就认为人和公司、公司和办公室之间存在某种语义上的联系。

在分析设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建立关联关系。

在图2中最上部存在一个属于\\\/签定关联:每个保险单属于一个客户,而客户可以签定多个保险单。

除了这个关联外,图1中还有另外两个关联,分别表示每个保险单包含若干个保险单上的项目,而每个保险单上的项目涉及单一的保险类别。

· 关联的方向关联可以有方向,表示该关联单方向被使用。

关联上加上箭头表示方向,在UML中称为导航(Navigability)。

我们将只在一个方向上存在导航表示的关联,称作单向关联 ( Uni-directional Association ),在两个方向上都有导航表示的关联,称作双向关联 ( Bi-directional Association )。

图2中,保险单“保险单上的项目”是单向关联。

UML规定,不带箭头的关联可以意味着未知、未确定或者该关联是双向关联三种选择,因此,在图中应明确使用其中的一种选择。

· 关联的命名既然关联可以是双向的,最复杂的命名方法是每个方向上给出一个名字,这样的关联有两个名字。

（见图2中最上部的属于\\\/签定关联)。

为关联命名有几种方法,其原则是该命名是否有助于理解该模型。

· 角色关联两头的类以某种角色参与关联。

例如图3中，公司以雇主的角色,人以雇员的角色参与的工作合同关联。

雇主和雇员称为角色名。

如果在关联上没有标出角色名,则隐含地用类的名称作为角色名。

角色还具有多重性(Multiplicity),表示可以有多少个对象参与该关联。

在图3中,雇主(公司)可以雇佣(签工作合同)多个雇员,表示为*;雇员只能与一家雇主签定工作合同,表示为1。

多重性表示参与对象的数目的上下界限制。

*代表0～∞,即一个客户可以没有保险单,也可以有任意多的保险单。

1是1..1的简写,即任何一个保险单仅来自于一个客户,可以用一个单个数字表示,也可以用范围或者是数字和范围不连续的组合表示。

图3 关联的角色 · 关联类一个关联可能要记录一些信息,可以引入一个关联类来记录。

图4是在图3的基础上引入了关联类。

关联类通过一根虚线与关联连接。

图5是实现上述目标的另外一种方法,就是使雇用关系成为一个正式的类。

图4 关联类图5 另一种实现方法 · 聚集和组成聚集(Aggregation)是一种特殊形式的关联。

聚集表示类之间的关系是整体与部分的关系。

一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是聚集的一个例子。

在需求分析中,包含、组成、分为……部分等经常设计成聚集关系。

聚集可以进一步划分成共享聚集(Shared Aggregation)和组成。

例如,课题组包含许多成员,但是每个成员又可以是另一个课题组的成员,即部分可以参加多个整体,我们称之为共享聚集。

另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失,这称为组成(Composition)。

例如,我们打开一个视窗口,它就由标题、外框和显示区所组成。

一旦消亡则各部分同时消失。

在UML中,聚集表示为空心菱形,组成表示为实心菱形。

需要注意的是,一些面向对象大师对聚集的定义并不一样。

大家应注意其他面向对象方法与UML中所定义的聚集的差别。

继承关系人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。

例如,动物可分为飞鸟和走兽,人可分为男人和女人。

在面向对象方法中将前者称为一般元素、基类元素或父元素,将后者称为特殊元素或子元素。

继承(Generalization)定义了一般元素和特殊元素之间的分类关系。

在UML中,继承表示为一头为空心三角形的连线。

如图2中,将客户进一步分类成个体客户和团体客户,使用的就是继承关系。

在UML定义中对继承有三个要求: *特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也都隐含性地具有; *特殊元素还应包含额外信息; *允许使用一般元素实例的地方,也应能使用特殊元素。

依赖关系有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。

在类中,依赖由各种原因引起,如:一个类向另一个类发消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。

如果一个类的界面改变,它发出的任何消息可能不再合法。

发表者：nuaalfm(方明) - - 2006-08-02 02:56 解析UML的静态建模机制（3）类图的抽象层次和细化(Refinement)关系需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次的抽象。

在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接口;而在实现阶段,类图描述软件系统中类的实现。

按照Steve Cook和John Dianiels的观点,类图分为三个层次。

需要说明的是,这个观点同样也适合于其他任何模型,只是在类图中显得更为突出。

· 概念层概念层(Conceptual)类图描述应用领域中的概念。

实现它们的类可以从这些概念中得出,但两者并没有直接的映射关系。

事实上,一个概念模型应独立于实现它的软件和程序设计语言。

· 说明层说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分。

面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这一差异。

这主要是因为OO语言中类的概念将接口与实现合在了一起。

大多数方法由于受到语言的影响,也仿效了这一做法。

现在这种情况正在发生变化。

可以用一个类型(Type )描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现。

· 实现层只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部分。

这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流。

理解以上层次对于画类图和读懂类图都是至关重要的。

但是由于各层次之间没有一个清晰的界限,所以大多数建模者在画图时没能对其加以区分。

画图时,要从一个清晰的层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。

要正确地理解类图,首先应正确地理解上述三种层次。

虽然将类图分成三个层次的观点并不是UML的组成部分,但是它们对于建模或者评价模型非常有用。

尽管迄今为止人们似乎更强调实现层类图,但这三个层次都可应用于UML,而且实际上另外两个层次的类图更有用。

下面介绍细化概念。

细化是UML中的术语,表示对事物更详细一层的描述。

两个元素A、B描述同一件事物,它们的区别是抽象层次不同,若元素B是在元素A的基础上的更详细的描述,则称元素B细化了元素A,或称元素A细化成元素B。

细化的图形表示为由元素B指向元素A的、一头为空心三角的虚线(千万不要把方向颠倒了!)。

细化主要用于模型之间的合作,表示开发各阶段不同层次抽象模型的相关性,常用于跟踪模型的演变。

约束在UML中,可以用约束(Constraint)表示规则。

约束是放在括号{}中的一个表达式,表示一个永真的逻辑陈述。

在程序设计语言中,约束可以由断言(Assertion)来实现。

对象图、对象和链 UML中对象图与类图具有相同的表示形式。

对象图可以看作是类图的一个实例。

对象是类的实例;对象之间的链(Link)是类之间的关联的实例。

对象与类的图形表示相似,均为划分成两个格子的长方形(下面的格子可省略)。

上面的格子是对象名,对象名下有下划线;下面的格子记录属性值。

链的图形表示与关联相似。

对象图常用于表示复杂的类图的一个实例。

包一个最古老的软件方法问题是:怎样将大系统拆分成小系统。

解决这个问题的一个思路是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。

这个思路被松散地应用到许多对象技术中。

UML中这种分组机制叫包(Package)(见图6)。

图6 包图不仅是类,任何模型元素都运用包的机制。

如果没有任何启发性原则来指导类的分组,分组方法就是任意的。

在UML中,最有用的和强调最多的启发性原则就是依赖。

包图主要显示类的包以及这些包之间的依赖关系。

有时还显示包和包之间的继承关系和组成关系。

· 包的内容在图6中,系统内部包由保险单包和客户包组成。

这里称保险单包和客户包为系统内部包的内容。

当不需要显示包的内容时,包的名字放入主方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内。

包的内容可以是类的列表,也可以是另一个包图,还可以是一个类图。

· 包的依赖和继承图6中保险单填写界面包依赖于保险单包;整个系统内部包依赖于数据库界面包。

可以使用继承中通用和特例的概念来说明通用包和专用包之间的关系。

例如,专用包必须符合通用包的界面,与类继承关系类似。

通过数据库界面包,系统内部包既能够使用Oracle的界面也可使用Sybase的界面。

通用包可标记为{abs tract},表示该包只是定义了一个界面,具体实现则由专用包来完成。

其他模型元素和表示机制类图中用到的模型元素和表示机制较为丰富,由于篇幅的限制,这里不能一一介绍。

主要还有以下模型符号和概念:类

java开发工程师一般都做什么开发

bai、Java Web，包括 Java Oracle 编程JDBC；、JavaWeb编程，包括JSP、Servlet,JavaBean；、Java应用编程，包括Weblogic、Websphere、Tomcat以及Jbuilder开发Java程序；、MVC与Struts，学习业界通用的MVC设计模式和Struts架构。

求一篇《软件工程导论》（第五版）的读后感，2000字左右，谢谢大家了，急用

1、软件工程是一门指导软件开发和维护的工程学科，主要研究软件开发和维护的工程技术和软件项目管理等内容，其中涉及如何保证软件产品的质量和可靠性，如何提高软件开发效率和拥护满意度等。

2、软件工程目标：生产具有正确性、可用性以及开销合宜的产品。

正确性指软件产品达到预期功能的程度。

可用性指软件基本结构、实现及文档为用户可用的程度。

开销合宜是指软件开发、运行的整个开销满足用户要求的程度。

这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。

3、软件生产历经4大阶段分别为：程序设计阶段（1946-1956年）、软件开发阶段（1956-1968年）、软件工程阶段（1968年以后）、计算机辅助软件工程阶段4、常见的软件过程模型：边改边做模型、瀑布模型、演化模型、增量迭代模型、喷泉模型5、软件过程的研究，标志着人们为解决软件危机问题，把关注的焦点由编程转移到了软件开发的整个过程，包括分析、设计、编程和测试4个核心阶段和需求调研、运行与维护两个延伸阶段说明软件质量、软件开发效率、软件的可靠性、可维护性问题涉及了软件生存周期的所有阶段。

6、软件生存周期：一个软件从定义到开发、使用和维护，直到最终被弃用，要经历一个漫长的时期，通常把软件经历的这个漫长的时期称为生存周期。

软件的生存周期可分为八个阶段：①问题定义；②可行性研究；③需求分析；④总体（概要）设计；⑤详细设计；⑥编码与单元测试；⑦综合测试；⑧软件维护。

7、需求分析：系统开发前期需求分析很重要，它是为了有效解决用户问题的需要进行的一项工程活动，所需要考虑的需求问题是功能需求、数据需求、性能需求和接口需求，开发者承担分析任务，核心是用户。

其步骤有三个：①获取客户需求，客户泛指某个人或机构部门等，一般方法是调查，包括访谈、座谈、问卷、跟班和收集资料，需求规约可表达用户的软件价值。

②建立需求模型，它是用户需求的图解，一些常用的模型有：业务树图、用例图、活动图。

分别用于结构化需求建模、系统业务举例和反映系统工作流程。

③进行需求验证，要验证的主要内容有：有效性验证、一致性验证、完整性验证、现实性验证和可检验性验证。

。

感悟：了解了什么是“软件危机”，透过软件工程于解决“软件危机”的重要性、软件工程三条重要线索、软件工程知识体系函括内容及软件工程各类生存期模型，我对软件工程思想及“工程化”软件开发的流程有了较系统的了解，透过软件工程的起源，认识到：实现软件工业的产业化，软件工程必须是真正意义上的工程化。

从软件开发三条线索（开发、管理、改进）来看，软件开发的过程必须规范化（各阶段都必须形成相应文档；编码必须依照通用可读性严格遵照编程规范……）；软件项目管理的核心是项目规划和项目跟踪控制，保证软件工程开发的成功完成，软件开发流程的规范化在软件项目中有着重要的作用，通过不断地优化和规范过程，企业可以提高软件生产能力。

从需求分析到维护，透过软件的开发流程具体实施的学习，我对软件项目开发的流程有了更深的理解，例如通过需求规格说明书、可行性研究说明书、数据库设计说明书、需求分析说明书、总体设计说明书、详细设计说明书等六份作业的完成虽然很不完善，但仍让我对需求分析建模和设计中用到的方法有了更好的理解并熟悉了六份文档的格式。