第五章面向对象分析与设计（上）

雨声萦回

于 2024-06-23 16:03:49 发布

阅读量614

点赞数 8

分类专栏：软件工程笔记文章标签：软件工程学习 java

本文链接：https://blog.csdn.net/Wander_InTheRain/article/details/139899702

版权

软件工程笔记专栏收录该内容

6 篇文章 0 订阅

订阅专栏

一、面向对象的基本概念

1.面向对象技术概述

面向对象
– 任何系统都是由能够完成一组相关任务的对象构成
– 如果对象依赖于一个不属于它负责的任务，那么就需要访问负责此任务的另一个对象(调用其他对象的方法)
– 一个对象不能直接操作另一个对象内部的数据，它也不能使其它对象直接访问自己的数据
– 所有的交流都必须通过方法调用

1.1结构化程序开发

每一步骤都是带有预定输入和特定输出的一个过程;
§ 把这些步骤串联在一起可产生合理的稳定的贯通于整个程序的控制流，最终产生一个简单的具有静态结构的体系结构;
§ 数据抽象、数据结构根据算法步骤的要求开发，它贯穿于过程，提供
过程所要求操作的信息;
§ 系统的状态是一组全局变量，这组全局变量保存状态的值，把它们从一个过程传送到另一个过程。
§ 结构化软件=算法+数据结构
§ 结构化需求分析= 结构化语言+数据字典(DD)+数据流图(DFD)

问题：

结构化方法以功能分解和数据流为核心，但是...系统功能和数据表示极有可能发生变化;

1.2面向对象软件开发

§ 在结构化程序开发模式中优先考虑的是过程抽象，在面向对象开发模式中优先考虑的是实体(问题论域的对象);
§ 主要考虑对象的行为而不是必须执行的一系列动作

§ 面向对象分析(Object Oriented Analysis, OOA)
– 分析和理解问题域，找出描述问题域和系统责任所需的类及对象，分析它们
的内部构成和外部关系，建立OOA 模型。
§ 面向对象设计(Object Oriented Design, OOD)
– 将OOA 模型直接变成OOD 模型，并且补充与一些实现有关的部分，如人机界面、数据存储、任务管理等。
§ 面向对象编程(Object Oriented Programming, OOP)
– 用一种面向对象的编程语言将OOD 模型中的各个成分编写成程序，由于从 OOA→OOD→OOP实现了无缝连接和平滑过渡，因此提高了开发工作的效率和质量

2.面向对象的基本概念

面向对象=对象+类 +继承+消息

2.1对象(Object)

§ 对象(Object):具有责任的实体。用来描述客观事物的实体，是构成系统的一个基本单位，由一组属性以及作用在这组属性的操作构成。
§ Object::=(OID, DS, OS, MI) (标识，数据结构，操作集，消息集)

§ 构成三要素:标识符(区别其他对象)、属性(状态)和操作(行为)。
– 属性(Attribute):与对象关联的数据，描述对象静态特性;

– 操作(Operation):与对象关联的程序，描述对象动态特性;

2.2类

§ 类(Class):具有相同属性和操作的一组对象的抽象，它为属于该类的全部对象提供了统一的抽象描述。
– 类是概念定义，抽象了同类对象共同的属性和操作

– 对象是类的一个实例
§ Class::=<ID, DS, OP, ITF, INH> (标识，数据结构描述，操作集合，外部接口，继承性描述)
§ “类”所代表的是一个抽象的概念或事物，现实世界中并不存在，而 “对象”是客观存在的。

（1）类的命名

尽量采用代表真实世界的事物去命名。

（2）类的属性

§ 类的属性:描述对象“静态”(结构)特征的一个数据项;
§ 属性的“可见性”(Visibility)分类:

– 公有属性(public) +
– 私有属性(private) -
– 保护属性(protected) #
§ 属性的表达方式:
– 可见性属性名:数据类型=初始值
（3）类的操作/方法/服务(Operation/Method/Service)

§ 类的操作:描述对象“动态”(行为)的特征的一个函数或过程;
§ 方法的“可见性”(Visibility)分类:

– 公有属性(public) +
– 私有属性(private) -
– 保护属性(protected) #
§ 方法的表达方式:
– 可见性方法名(参数列表):返回值数据类型
– 例如:+ getNextSentence (int i) : string

（4）类的作用

§ 类是一个支持继承的抽象数据类型;
§ 类是创建(实例化)对象的模板，类是对对象的抽象;

§ 类是一个命名空间，为类的泛化声明建立作用域;

§ 类类似一张表，表内描述了数据和操作的封装体。

2.3消息(Message)

一个对象向其他对象发出的请求，一般包含消息接收对象、接收对象所采用的方法、方法需要的参数、返回信息等;

2.4封装

把对象的属性和操作结合成一个独立的单元，并尽可能对外界隐藏对象的内部实现细节

封装的作用：

– 数据的安全性:保护对象，避免用户误用。
– 模块的独立性:保护客户端(调用程序)，其实现过程的改变不会影响到相应客户端的改变。
– 易开发、易维护性:隐藏复杂性，降低了软件系统开发难度;各模块独立组件修改方便，重用性好。

2.5泛化(Generalization)与继承(Inheritance)

§ 泛化(generalization)/继承(Inheritance) 关系是类元的一般描述和具体描述之间的关系，具体描述建立在一般描述的基础之上，并对其进行了扩展。

§ 继承(Inheritance):子类( Subclass)可自动拥有父类/超类(SuperClass)的全部属性和操作;

2.6多态(Polymorphism)

在父类中定义的属性或服务被子类继承后，可以具有不同的数据类型或表现出不同的行为。

2.7抽象类(abstract class)与接口(Interface)

把一些类组织起来，提供一些公共的行为，但不能使用这个类的实例(即从该类中派生出具体的对象)，而仅仅能使用其子类的实例。称不能建立实例的类为抽象类。

接口(Interface):描述了一个类的一组外部可用的属性和服务(操作)集

接口定义的是一组属性和操作的描述，而不是操作的实现，体现了“接口与实现的分离”的思想，即“信息隐藏”。

3.对象之间的五类关系

3.1分类结构:继承/泛化关系

表示的是事物的“一般‐特殊”的关系，也称为泛化 (Generalization)联系。

3.2组成结构:聚合与组合关系

表示对象类之间的组成关系，一个对象是另一个对象的组成部分，即“部分-整体”关系。

聚合(Aggregation):整体与部分在生命周期上是独立的

组合(Composition):强调整体与部分具有同样的生命周期;

3.3实例连接:关联关系

表示对象之间的静态联系，通过对象的属性之间的联系加以展现。

§ 关联具有多重性(重数):表示可以有多少个对象参与该关联

§ 关联具有方向性

3.4消息连接:依赖关系

§ 消息连接
– 消息连接是对象之间的通信联系，它表现了对象行为的动态联系。
– 一个对象需要另一个对象的服务，便向它发出请求服务的消息，接收消息的对象响应消息，触发所要求的服务操作。
§ 消息连接也称为“依赖关系”(Dependency)

– 依赖是一种使用关系，一个类A使用到了另一个类B，而这种使用关系是偶然性的、临时性的、非常弱的，但是B类的变化会影响到A。

3.5接口连接:实现关系

是泛化关系和依赖关系的结合，通常用以描述一个接口和实现它们的类之间的关系;

4.UML建模语言简述

统一建模语言( Unified Modeling Language，UML)是描述、构造和文档化系统制品的可视化语言(OMG03a)。

UML的定义包括UML语义和UML表示法两个部分。
– UML语义:UML对语义的描述使开发者能在语义上取得一致认识，消除了因人而异的表达方法所造成的影响。
– UML表示法:UML表示法定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。

4.1UML视图和图

（1）UML视图

§ 结构分类:描述了系统中的结构成员及其相互关系
– 静态视图对应用领域中的概念以及与系统实现有关的内部概念建模
– 物理视图对应用自身的实现结构建模。

§ 行为分类:描述了系统的功能和行为
– 用例视图是外部用户所能观察到的系统功能的模型图
– 状态机视图是一个类对象所可能经历的所有历程的模型图。
– 活动视图是状态机的一个变体，用来描述执行算法或工作流程中涉及的活动 – 交互视图描述了执行系统功能的各个角色之间相互传递消息的顺序关系。

（2）UML图

§ 类图/对象图:描述系统的各个对象类型以及存在的各种静态关系 § 用例图:描述用户与系统如何交互
§ 构件图:构件间的组织结构及链接关系
§ 部署图:制品在节点上的部署
§ 状态图:事件在对象的周期内如何改变状态
§ 活动图:过程及并行行为
§ 顺序图:对象间的交互;强调顺序
§ 协作图:对象间交互，重点在对象间链接关系

4.2各UML图及特征

（1）用例图( Use Case Diagram )
– 描述用户与系统如何交互。从用户角度描述系统功能，是用户所能观察到的系统功能的模型图，用例是系统中的一个功能单元。

（2）类图(Class Diagram)/对象图(Object Diagram)
– 描述系统的各个对象类型以及存在的各种静态关系。对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实际的类。

（3）顺序图(Sequence Diagram)
– 顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互

（4）协作图

– 对象间交互，重点在对象间链接关系;
– 协作图描述对象间的协作关系，协作图跟顺序图相似，显示对象间的动态合作关系。除显示信息交换外，协作图还显示对象以及它们之间的关系.
– 协作图的一个用途是表示一个类操作的实现

（5）状态图(State Chart Diagram)
– 事件在对象的周期内如何改变状态;
– 状态图是一个类对象所可能经历的所有历程的模型图。状态图由对象的各个状态和连接这些状态的转换组成

（6）活动图(Activity Diagram)
– 活动图是状态图的一个变体，用来描述执行算法的工作流程中涉及的活动

– 活动图描述了一组顺序的或并发的活动
– 过程及并行行为

（7）包图(Package Diagram)
– 包图是在 UML 中用类似于文件夹的符号表示的模型元素的组合。
– 把在语义上接近且倾向于一起变化的类组织在一起形成“包”，既可控制模型的复杂度，有助于理解，而且也有助于按组来控制类的可见性;

（8）构件图(Component Diagram)

– 构件间的组织结构及链接关系
– 构件图为系统的构件建模型—构件即构造应用的软件单元—还包括各构件之间的依赖关系，以便通过这些依赖关系来估计对系统构件的修改给系统可能带来的影响

（9）部署图(Deployment Diagram)
– 部署视图描述位于节点实例上的运行构件实例的安排。节点是一组运行资源，如计算机、设备或存储器。这个视图允许评估分配结果和资源分配。

4.3主流的UML建模工具

– Enterprise Architect

– Visual Paradigm
– Microsoft Visio
– StarUML

二、面向对象的分析

1.面向对象的分析方法概述

§ 着重分析业务领域和系统责任，建立独立于实现的OOA模型，暂时忽略与系统实现有关的问题。
§ 主要使用5种图描述完整的系统需求:
– 用例图 – 类图
– 时序图 – 协作图 – 状态图

1.1面向对象的分析建模

面向对象的分析模型由三个独立的模型构成:
– 功能模型:从用户的角度获取功能需求，由用例模型表示
– 静态结构模型(分析对象模型):描述系统的概念实体，由类图表示;
– 动态行为模型:描述对象之间的交互行为，由顺序图和协作图表示。

1.2面向对象分析的过程

§ 第一阶段:业务领域分析（用例模型）
– 分析应用领域的业务范围、业务规则和业务处理过程，确定系统的责任、范
围和边界，确定系统的需求。
– 在分析中需要着重对系统与外部的用户和其他系统的交互进行分析，确定交互的内容、步骤和顺序。

§ 第二阶段:发现和定义对象和类
– 识别对象和类，确定它们的内部特征:属性与服务操作。
– 这是一个从现实世界到概念模型的抽象过程，而抽象是面向对象分析的基本原则。
§ 第三阶段:识别对象的外部联系
– 在发现和定义对象和类的过程中，需要同时识别对象与对象、类与类之间的
各种外部联系，如一般与特殊、整体与部分、实例连接(关联)、消息连接等联系。
– 对象和类是现实世界中的事物的抽象，它们之间的联系也要从分析现实世界事物的各种真实的联系中获得。

§ 第四阶段:建立系统的静态结构模型
– 分析系统的行为，建立系统的静态结构模型，并将其用图形和文字说明表示
出来，如绘制类图、对象图、系统与子系统结构图等，编制相应说明文档。
§ 第五阶段:建立系统的动态行为模型
– 分析系统的行为，建立系统的动态行为模型，并将其用图形和文字说明表示出来，如绘制用例图、交互图、活动图、状态图等，编制相应的说明文档。

2.建立静态结构模型

§ 基本的分析过程:
– Step 1:从用例模型入手，识别分析类;

– Step 2:描述各个类的属性;
– Step 3:定义各个类的操作;
– Step 4:建立类之间的关系;
– Step 5:绘制类图(class diagram)

2.1分析类

§ 分析类是概念层次上的内容，用于描述系统中较高层次的对象 § 分析类直接与应用逻辑相关，而不关注于技术实现的问题
§ 分析类的类型:
– 实体类:表示系统存储和管理的持久性信息
– 边界类:表示参与者与系统之间的交互
– 控制类:表示系统在运行过程中的业务控制逻辑

2.2边界类

– 描述外部的参与者与系统之间的交互;
– 目的:将用例的内部逻辑与外部环境进行隔离，使得外界的变化不会影响到内部的逻辑部分;
– 类型:用户界面、系统接口、设备接口。

2.3控制类

– 描述一个用例所具有的事件流的控制行为，本身并不处理具体的任务，而是调度其他类来完成具体的任务;
– 实现了对用例行为的封装，将用例的执行逻辑与边界和实体进行隔离，使得边界类和实体类有较好的通用性

2.4实体类

– 描述必须存贮的信息及其相关行为;
– 对系统的核心信息建模，通常这些信息需要长久的保存;

– 通常对应现实世界中的“事物”。

2.6 Step 1:识别分析类

方法1:重用和修改现有的模型

方法2:使用分类列表(不同领域不同的分类列表)

方法3:对用例文本进行“语法分析”

§ 识别边界类
– 通常，一个参与者与一个用例之间的交互或通信关联对应一个边界类。

§ 识别控制类
– 控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物;
– 负责接收边界类的信息，并将其分发给实体类;
– 控制类与用例存在着密切的关系，它在用例开始执行时创建，在用例结束时取消。一般来说一个用例对应一个控制类。

§ 识别实体类

找到“实体类”?，——名词驱动的识别方法

2.7 Step 2:描述分析类的属性

“什么数据项(组合项和/或基本项)能够在当前问题环境内完整地定义这个类?”

§ 按照一般常识，找出对象的某些属性; – 人员的姓名、性别、年龄、地址等;
§ 认真研究问题域，找出对象的某些属性; – 商品的条形码、学生的学号;
§ 根据系统责任的要求，找出对象的某些属性;
§ 考虑对象需要系统保存的信息，找出对象的相应属性;
§ 对象为了在服务中实现其功能，需要增设一些属性;
§ 识别对象需要区别的状态，考虑是否需要增加一个属性来区别这些状态;
§ 确定属性表示整体与部分结构和实例连接。

2.8 Step 3:定义分析类的操作

§ 将用例行为分配到相应的分析类之后，系统的一些分析类具有相应的
职责。可通过动词分析获得操作。
§ 操作的四种类型:
– 以某种方式操作数据(例如:增加、删除、重新格式化、选择); – 执行计算的操作;
– 请求某个对象的状态的操作;
– 监视某个对象发生某个控制事件的操作。

2.9 Step 4:建立类之间的关系

§ 五种关系:
– 泛化(generalization) – 关联(association)
– 组合(composition) – 聚合(aggregation)
– 依赖(dependency)

2.10 Step 5:绘制类图

§ 两种类图:
– 分析类图:描述各边界类、实体类、控制类之间的关联关系，无需刻画属性
与操作集;
– 领域类图:可以不包含边界类与控制类，侧重描述各实体类之间的五种关系，需要给出详细的属性与操作集合

3.建立动态行为模型

§ 动态行为模型可用两个新视图描述:

– 时序图/顺序图(Sequence Diagram)
– 协作图(Collaboration Diagram)

3.1时序图

将用户与分析类结合在一起，实现将用例的行为分配到所识别的分析类中;

§ 时序图是强调消息时间顺序的交互图;
§ 时序图描述了对象之间传送消息的时间顺序，表示用例中的行为顺序;
§ 时序图将交互关系表示为一个二维图。其中，纵轴是时间轴，时间沿竖线向下延伸;横轴代表了在协作中各独立的对象。

3.2时序图的组成

§ 对象(Object):类的实例
§ 生命线(Lifeline):生命线是一个时间线 § 消息(Message):对象方法的调用
§ 激活(Activation) :对象的状态

3.3消息

§ 消息定义的是对象之间某种形式的通信，它可以激发某个操作、唤起信号或导致目标对象的创建或撤销。
§ 消息是两个对象之间的单路通信，从发送方到接收方的控制信息流。
§ 消息可以用于在对象间传递参数。
§ 消息可以是信号，也可以是调用。
§ 在UML中，消息使用箭头来表示，箭头的类型表示了消息的类型。

3.4时序模型

§ 时序模型中的每一列:本质上是object，每个出现的 object，其相应的class必须都在分析类模型/领域模型中已经定义过了。

§ 出现在时序图中的箭头，UML中分了六种类型:
– Create:obj1调用Class2的new操作，创建出obj2实例
– Call:obj1调用obj2的某个操作
– Return:obj2被调用的操作执行结束后，将结果返回obj1

– Self-call:obj2自己调用自己内部的某个操作;
– Send:obj1向obj2发送消息来触发(而不直接调用其操作)

– Destroy:obj1调用Class2的destroy操作，销毁obj2实例。

– 图形表示方式分别如右图中的1~6箭头所示。

3.5激活

§ 激活表示该对象被占用以完成某个任务，去激活指的则是对象处于空闲状态、在等待消息。
§ 在UML中，为了表示对象是激活的，可以将该对象的生命线拓宽成为矩形。其中的矩形称为激活条或控制期，对象就是在激活条的顶部被激活的，对象在完成自己的工作后被去激活。

3.6时序模型建模过程

§ 时序图/顺序图(Sequence Diagram):将用户与分析类结合在一起，实现将用例的行为分配到所识别的分析类中;
§ 绘制步骤:
– 列出启动该用例的参与者;
– 列出启动用例时参与者使用的边界对象;
– 列出管理该用例的控制对象;
– 根据用例描述的流程，按时间顺序列出分析类之间进行消息访问的序列

（1）系统顺序图(每一个用例)

（2）分析对象顺序图

§ 将用户请求与分析类结合在一起，按照职责分配的原则，通过分析类的协作实现对用户的服务

4.软件需求规格说明书

§ 软件需求规格说明书SRS (Software Requirements Specification):

– 需求开发的结果，精确的阐述一个软件系统必须提供的功能和性能，以及它所要考虑的限制条件。
– 为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

4.1SRS应包含的内容

§ 功能(Functionality):
– 该软件系统能够向用户提供何种服务?
§ 外部接口(External interfaces):
– 该软件系统如何与用户、操作系统、硬件、其他软件系统进行交互?
§ 性能(Performance):
– 软件系统在运行速度、可用性、响应时间、恢复时间等方面有哪些要求?
§ 非功能属性(Non-Functional Attributes):
– 软件系统在可移植性、安全性、可靠性、可维护性等方面有哪些要求?
§ 约束条件(Design constraints imposed on an implementation): – 是否存在必要的标准、编程语言、运行环境、资源约束等因素?

4.2SRS不应包含的内容

§ 项目开发计划
– 诸如成本、人员、进度、工具、方法等
§ 产品保证计划
– 诸如配置管理、验证与测试、质量保证等
§ 软件设计细节
– 需求通常用于表达“做什么”，而不描述“如何做”

4.3编写需求规格说明的原则

§ 原则1:只描述“做什么”而无须描述“怎么做”
§ 原则2:必须说明运行环境
§ 原则3:考虑用户、分析员和实现者的交流

– 对形式化和自然语言之间作出恰当的选择
– 明确的理解最重要，不存在十全十美的软件规格说明书

§ 原则4:力求寻找到恰如其分的需求详细程度
– 一个有益的原则就是编写单个的可测试需求文档
– 建议将可测试的需求作为衡量软件产品规模大小的尺度

§ 原则5:文档段落不宜太长

– 简短
– 记住:不要在需求说明中使用“和/或”、“等等”之类的词
§ 原则6:避免使用模糊的、主观的术语
– 如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等
– 不可验证

5.需求验证和需求管理

§ 需求验证:通过确定以下几方面的内容来检验需求能否满足客户的意愿
– 从用户需求或其它来源中得到软件需求
– 软件需求规格说明正确描述了预期的系统行为和特征
– 需求是完整的和高质量的
– 所有对需求的看法是一致的
– 需求为继续进行产品设计、构造和测试提供了足够的基础

三、软件设计概论

1.软件设计的背景

§ 软件设计:为问题域的外部可见行为的规约增添实际的计算机系统实现所需的细节，包括关于人机交互、任务管理和数据管理的细节。

1.1良好的软件设计的三个特征

§ 目标:设计必须是实现所有包含在分析模型中的明确需求，满足利益相关者期望的所有隐含需求;
§ 形态:对开发、测试和维护人员来说，设计必须是可读的、可理解的、可操作的指南;
§ 内容:设计必须提供软件的全貌，从实现的角度去说明功能、数据、行为等各个方面。

1.2软件质量

§ 外部质量:面向最终用户
– 如易用性、效率、可靠性、正确性、完整性等
§ 内部质量:面向软件工程师，技术的角度
– 如可维护性、灵活性、可重用性、可测试性等

1.3软件设计的方式

§ 方式:先实现多样化再进行聚合

– 多样化:找到各种可能的解决方案

– 聚合:折中选取最适合的
§ 多样化和聚合需要直觉和判断力，其质量取决于
– 构造类似实体的经验
– 一系列指导模型演化方式的原则和(或)启发
– 一系列质量评价的标准以及导出最终设计表示的迭代过程

2.软件设计中的核心概念

2.1设计概念

§ 抽象:强调关键特征，忽略实现细节
– 过程抽象:具有明确和有限功能的指令序列

– 数据抽象:描述数据对象的冠名数据集合
§ 体系结构:程序构件(模块)的结构、构件交互的形式、构件的数据结构
– 功能模型:表示系统的功能层次结构
– 框架模型:解决某一类问题的处理流程
– 结构模型:程序构件的一个有组织的集合

§ 关注点分离:关注点是一个特征或行为，软件需求模型的一部分;任何复杂问题如果被分解为可以独立解决和优化的若干块，该复杂问题能够更容易地被处理;
§ 模块化:关注点分离最常见的表现，分治策略，将软件划分为独立构件(模块)
– 合理划分模块数量

§ 信息隐藏:每个模块对其他所有模块都隐藏自己的设计决策

– 软件只通过定义清晰的接口通信
– 每一个接口尽可能暴露最少的信息
– 如果内部细节发生变化，外部的受到影响应当最小
§ 功能独立:是关注点分离、模块化、抽象概念和信息隐藏的结果

– 功能专一，避免与其他模块过多交互
– 独立性的评价:内聚性和耦合性

§ 求精:
– 逐步求精 – 分解细化 – 层次结构

§ 重构:是一种重新组织的技术，不改变外部行为而是改进内部结构

§ 设计类:精化分析类、创建新的设计类
– 用户接口类(边界类):人机交互所必需的抽象 – 领域类(实体类):分析类的精化
– 过程类(控制类):底层业务抽象
– 持久类:持续存在的数据存储
– 系统类:软件管理和控制功能

§ 模式:特定问题的解决方案
§ 体系结构模式:定义软件的整体结构，体现了子系统和软件构件之间的关系，并定义了说明体系结构元素(类、包、构件、子系统)之间关系的规则
§ 设计模式:这些模式解决设计中特有的元素，例如解决某些设计问题中的构件聚集、构件间的联系或影响构件到构件之间通信的机制
§ 框架(Framework):已实现的特定的骨架基础设施，提供了基础功能，并规定了构件及构件的连接方式。开发者只需要将注意力集中于业务逻辑的实现

2.2设计建模原则

§ 设计可追溯到分析模型
§ 经常关注待建系统的架构
§ 数据设计与功能设计同等重要
§ 必须设计接口(包括内部接口和外部接口)
§ 用户界面设计必须符合最终用户要求
§ 功能独立的构件级设计
§ 构件之间以及构件与外部环境之间松散耦合
§ 设计表述(模型)应该做到尽可能易于理解
§ 设计应该迭代式进行。每一次迭代，设计者都应该尽力简化

3.软件设计模型

3.1软件设计的四方面内容

3.2软件设计的元素

§ 体系结构设计:定义了软件的主要结构元素之间的联系，也用于达到系统所定义需求的体系结构风格和设计模式以及影响体系结构实现方式的约束
§ 接口设计:描述了软件和协作系统之间、软件和使用人员之间是如何通信的 § 数据/类设计:将分析类模型转化为设计类的实现以及软件实现所要求的数据
结构
§ 构件级设计:将软件体系结构的结构元素变换为对软件构件的过程性描述