1、软件体系结构：

       系统的一个或者多个结构，包括软件的构件，构件的外部可见属性及他们之间的相互关系。

2、设计类：

       在设计阶段，软件团队必须定义一组设计类，可以使用下面的方式：通过提供设计细节精化分析类，这些设计细节将促成类的实现；创建一组新的设计类，该设计类实现了软件的基础设施以支持业务解决方案。

       常用的五种设计类：用户接口类（定义人机交互所必需的所有抽象）、业务域类（通常是早期定义的分析类的精化）、过程类（实现完整管理业务域类所必需的低层业务抽象）、持久类（代表将在软件执行之外持续存在的数据存储）、系统类（实现软件管理和控制功能，似的系统能够运行并在其计算环境内与外界通讯）。

3、软件体系结构风格：

       一种风格描述一种系统类别，包括：（1）一组构件完成系统所需的某种功能；（2）一组连接器，它们能使构件间实现“通信、合作和协调”；（3）约束，定义构件如何集成为一个系统；（4）语义模型，它能使设计者通过分析系统的构成成分的性质来理解系统的整体性质。

       体系结构风格的简单分类：

       以数据为中心的体系结构：数据存储驻留在体系结构的中心，其他构件会经常访问数据存储，构件间相互独立。

       以数据流体系结构：数据像水流一样一次流过每个构件，所有构件单独完成对输入数据的处理，通过管道将数据传递给下一构件，构件间相互独立。当输入数据经过一系列的计算和操作构件的变换形成输出数据时，可应用该结构。

       调用和返回体系结构：可分为两种，一是主程序/子程序体系结构，一种是远程过程调用体系结构（主程序/子程序分布在不同计算机上）。

       面向对象体系结构：系统的构件封装了数据和必须应用到给数据的操作，构件间通过信息传递进行通信与合作。

       层次体系结构：定义不同的层次，每个层次各自完成操作，这些操作不断接近及其的指令集。

4、体系结构模式：

分析建模有两种方法结构化分析和面向对象的分析。

       结构化分析：考虑数据和处理。

       面向对象分析：关注定义类和影响客户需求的类之间的协作方式。

1、数据建模：

定义在系统内部处理的所有数据对象、数据对象间的关系以及其他与这些关系相关的信息（基数，1：1或1：n等；形态：0关系可有可无，1关系必须出现1次）。这里的数据对象只是封装数据，没有对数据的操作的引用（和面向对象方法中的对象有区别）。

辅助图形；实体-关系图。

2、基于场景建模：

       根据用例开发活动图、泳道图。

       辅助图形：活动图、泳道图。

3、数据流建模：

主要是生成数据流图，数据流图和系统流图类似，也是分层细化显示结构。在数据流图中实体对象用矩形表示，过程（转换）用椭圆形表示（泡泡），带标记的箭头代表数据对象，平行线表示数据文件。数据流图制作指导原则：（1）第0层的数据流图应将软件/系统描述为一个泡泡；（2）主要的输入和输出应被窒息地标记；（3）通过把下一层表示的候选处理过程、数据对象和数据存储分离，开始求精过程；（4）应使用有意义的名称标记所有的箭头和泡泡；（5）当从一层转到另一层时要保持信息流连续性；（6）一次精化一个泡泡。

处理规格说明：描述在求精过程中最终层次的所有流模型的处理，可以包括叙述性正文、处理算法的程序设计语言（PDL）描述、数学方程、表、图或图表。

4、控制流建模：

很多问题是事件驱动而不是数据驱动，对关注时间和性能的问题可以使用控制流建模。

控制规格说明（CSPEC）：包含一个状态图，该图是行为的序列说明；也可能靠扩程序激活表——行为的组合说明。

辅助图形：状态图。

5、基于类的建模：

       首先识别分析类，分析类可以是外部实体（系统、设备、人员等）、事物（报告、显示、字母、信号等，问题信息域的一部分）、角色（经理、工程师、销售人员）、组织单元、场地、结构等等（用例中的名词），再描述分析类的属性、操作。分析类可分为实体类、边界类、控制类。

       实体类：从问题的说明中直接提取出来。

       边界类：用于创建用户可见的和交互的接口。

       控制类：自始自终管理工作单元。

       CRC建模：一堆卡片，每张卡片表示一个类，顶部是类名，左边是职责，右边是协作者。分析师可以同过类之间是否有以下三种联系来识别协作者（1）is-part-of；（2）has-knowledge-of；（3）depends-upon。

需求工程通过七个不同的活动来完成：起始、导出、精华、协商、规格说明、确认和管理。

1、起始：

       对问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流和合作的效果建立基本的谅解。在其实阶段需要确认共同利益者，识别多种观点，标识这些观点的公共区域和矛盾区域。

2、导出：

       询问客户、用户和其他人，系统或产品的目标是什么。三种导出需求的方法。

       协同需求收集：召集有用共同利益者参加的会议，会有很多次。先要达成对问题和解决方案的整体理解共识，然后参会人员准备服务操作或与对象交互的服务列表、开发约束列表和性能标准，对这些列表合并，在会上对每个列表项目达成一致意见。

       质量功能部署：确认三类需求正常需求、期望需求、令人兴奋的需求。功能部署确定系统所需的每个功能的价值；信息部署确认系统必须使用和产生的数据对象和事件；任务部署在合适的环境下检查系统或产品的行为；价值分析确定三个部署中需求的相对优先级别。

       场景：即用例。

3、精化：

       开发一个精确的技术模型，用以说明软件的功能、特征和约束。精化是一个分析建模活动，最终形成分析模型，该模型定义了问题的信息域、功能域和行为域。

4、协商：

       当现实情况和用户目标相冲突时需要协商使各方满意。

5、规格说明：

       描述计算机系统的功能和性能，以及那些将影响系统开发的约束。

6、确认：

       确认要保证规格说明中所有的系统需求已被无歧义地说明；不一致性、疏漏和错误已被检测出并被纠正；工作产品符合为过程、项目和产品建立的标准。

7、需求管理：

       在项目进展中标识、控制和跟踪需求以及变更需求的一组活动。可使用各种跟踪表：

       特征跟踪表：显示需求与系统特征的关系。

       来源跟踪表：标识每个需求的来源。

       依赖跟踪表：指明需求间的依赖关系。

       子系统跟踪表：按照需求所控制的子系统对需求分类。

       接口跟踪表：显示需求与外部和内部系统接口的关系。

1、系统工程：

软件工程由系统工程演变而来，要了解软件工程应先了解系统工程。系统工程一般通过自顶向下、自底向上的方法，用层次结构来来分析整个系统。在系统工程层次图中自顶向下依次是全局视图（业务或产品域）——领域视图（关注全局中感兴趣领域）——要素视图（关注领域中系统要素）——详细视图（关注系统要素的组成要素），可以有很多层次，是个金字塔结构。

2、系统建模：

对于一个系统模型要定义在所考虑视图中满足需要的过程，描述过程行为和该行为所依据的假设，明确定义模型的外在和内在输入，描述有助于工程师理解视图的全部联系。

       系统建模中的制约因素：假设、简化、限制（确定系统边界）、约束、偏好。

基于计算机的系统：组织在一起通过处理信息来实现预定目标的要素集合或排列。

3、业务过程工程：

在实际软件工程中主要包含两种过程工程：业务过程工程和产品工程。

业务过程工程：定义一个能有效利用信息进行业务活动的体系。为一个组织（如企业）建立实施计算架构的总体计划提供一种方法。业务过程工程必须设计三种架构：

数据架构：为业务或业务功能的信息需求提供了框架，单独建立的框架模块是被业务所用到的数据对象。一个数据对象包括用于定义不同侧面的属性集、质量、特征或数据描述符。

应用架构：包含那些为了某些业务目的而在数据架构范围内进行转换的系统要素。一般是指执行转换的程序，也可包括人员角色和尚未实现自动化的业务规程。

技术基础设施：为数据架构和应用架构提供基础的软件、硬件设施。

业务过程工程层次图（自顶向下）：信息战略规划（实体：组织，对应系统工程中的全局视图）——业务区域分析（实体：业务区域，对应系统工程中的领域视图）——业务系统设计（实体：信息系统，对应系统工程中的要素视图）——构建和集成（实体：软件构件，对应系统工程的详细视图）。软件工程师主要工作在业务系统设计、构建和集成两个层次。

4、产品工程：

       将用户期望的以定义的一组能力转变成真实产品。

       产品工程层次图（自顶向下）：需求工程（实体：完整产品，对应全局视图）——构件工程（实体：软硬件，对应领域视图）——分析和设计建模（实体：数据、行为、功能，对应要素视图）——构建和集成（实体：程序构件，对应详细视图）。软件工程师主要工作在分析和设计建模、构建和集成两个层次。

5、软件工程中的系统建模：

       Haltey-pirbhai建模：将所有系统要素分派到五个模板处理过程中——用户界面、输入、系统功能和控制、输出、维护和自检。

       辅助图形：系统环境图和系统流图。

       系统环境图（SCD）：确定系统所使用信息的所有外部生产者、信息外部消费者、所有通过接口交流或者执行维护和自检的实体，建立待实现系统和系统操作环境之间的边界。

       系统流图（SFD）：展示主要子系统和重要信息流，子系统从SCD图中导出，流经SCD区域的信息流用于指导系统工程是制作系统流图。系统流图可分为很多层次，初始系统流图成为SFD层次的顶层节点。

6、UML系统建模：

最近在学软件工程，总结了对几种软件过程模型的理解，欢迎指正。

 1、软件工程：

       建立和使用一套合理的工程原则，从而经济地获得可靠的、可以在实际机器上高效运行的软件。（Fritz Bauer）

       将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化的方法应用于软件，以及对犯法的研究。（IEEE93）

       软件产生的过程。（笔者）

2、过程框架：

       定义若干小的框架活动，为完成软件开发过程建立了基础。这些框架活动可广泛应用于所有软件开发项目，无论这些小木的规模和复杂性如何。此外还包含一些适用于各个软件过程的普适性活动。

       通用过程框架：沟通、策划、建模、构建、部署。

3、过程模式：

       定义了一系列的软件开发中所需要的活动、动作、工作任务、工作产品及相关的行为，如原型开发，软件工程可定义为一系列模式的组合。

4、瀑布模型：

       一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供一个完整的软件并提供持续的技术支持。

5、增量过程模型：

       以迭代的方式运用瀑布模型，在瀑布模型的每个阶段运用线性序列，每个序列产生一个软件的可交付增量，每个序列中的过程可以交叉。

RAD模型：

       增量过程模型的改进版，只是沟通、策划只执行一次，每个线性序列只包含建模、构建、部署三个过程。

6、演进过程模型：

       原型开发模型：沟通—策划—建模—原型构建—部署—沟通，不断循环。

       螺旋模型：以原型开发为基础，只是把软件开发作为一系列演进版本，每一循环标记为里程碑。螺旋模型会贯穿整个软件生命周期。

       协同开发模型：为每个开发活动定义状态，一个活动状态的变更将引起其他活动状态的改变，可用于其他过程模型中，反映整个项目的状态。

7、专用过程模型：

       只是用于某些特定的软件工程方法。

       基于构件的开发模型：具有螺旋模型的许多特点，本质上是演化模型，需要以迭代的方式构建软件，不同之处是采用预先打包的软件构建开发程序。

       形式化方法模型：主要活动是生成计算机软件形式化的数学规格说明，软件工程师用严格的数学符号来说明、开发和验证基于计算机的系统。

       面向方面的软件开发模型：对纵向分解的软件构件进行横向切片，称为“方面”，以表示构件功能及非功能的横切属性。面向方面是对横切关注点局部表示的一种机制，超越了子程序和继承的方法。如果某个关注点（客户需要的属性或者技术兴趣点）涉及系统多个方面的功能、特性和信息，这些关注点成为横切关注点。

8、统一过程模型：