面向对象软件工程

Part-1

软件（技术）工程（管理）是一项建模活动/知识获取活动/受到软件工程原理指导的活动。

建模

面向对象方法将应用域和解答域建模活动合2而为1 应用域建模：一组对象和关系对应用域进行建模/

判断是应用域还是解答域的关键在于考虑对象和概念是描述现实世界问题（应用域），还是描述解决方案的一部分（解答域）。如果一个对象或概念是用来表示现实世界中的实体或现象，那么它属于应用域；如果一个对象或概念是用来表示解决问题的方法、算法或数据结构，那么它属于解答域。应用域关注具体的现实场景和需求，而解答域关注通用的解决方法和技巧。解答域问题的解决方案通常具有较高的通用性，可以应用于多个场景；而应用域问题的解决方案通常针对特定场景，可能无法直接应用于其他场景。解答域问题通常具有较高的抽象程度，与具体应用场景相对独立；而应用域问题则需要结合具体场景来分析和解决。

解答域建模模：由应用域模型转化过来的。面向对象方法的思想：软件开发标识并描述成一组模型集合的活动。

问题解决

面向对象的软件开发通常包括六种开发活动（还包括评价各种模型的合适性: 需求获取、需求分析、系统设计、对象设计、实现、测试 需求获取：问题形式化，构件问题域模型。需求分析：问题形式化，构件问题域模型。系统设计：大问题分解为小问题，采用通用策略设计系统，产生解答域模型。对象设计：为小问题选择最合适方案。产生解答域模型。实现阶段：解答域转化为可执行的表达。

软件工程不同于其它科学的是： 求解问题的过程中应用域和解答域在不断变化 分析审查（应用域模型）设计审查（解答域模型）

软件工程的概念

参与者：

售票系统TicketDistributor是一台发售火车票的
机器。旅客可以选择单程车票和多程车票，也可 以选择一天或一周的时间卡(time card)。售票系统TicketDistributor根据旅行地点、旅行者是成 人还是儿童来计算出旅客所要的车票价格。售票 系统必须能够处理一系列意外情况，例如系统可以处理没有完成交易的旅客情况，还可以处理试图使用巨额支票支付的情况，以及资源用尽的情 况，这一情况比如打印车票的纸张或者零钱用完了，或出现停电的情况等。

角色实例：
- 客户
- 用户
- 项目经理
- 开发者
售票系统TicketDistributor项目的软件工程的角色实例
角色 职责 例子
客户 客服负责... 把售票系统TicketDistributor承包出去的列车公司

系统(内部相互关联部分的集合)和模型：

例如， 一个地铁售票系统TicketDistributor就是一个系统。 售票系统TicketDistributor的蓝图、电线布线图、 软件的对象模型均是售票系统TicketDistributor的模型

活动、任务、资源：

活动:为完成某一目的所需的任务的集合。

需求获取-活动
交付-活动
管理-活动

任务：可管理的原子工作单位，任务消耗资源 资源：完成工作的资产。

售票系统TicketDistributor项目的活动、任务和资源的实例。
需求获取-活动
为售票系统开发 “没有零钱”的测试用例-任务
审视“获取在线帮助通路”的使用实例的可用性-任务
价目表数据库-资源

功能性需求和非功能性需求

功能性需求：系统必须支持的功能的规格说明。非功能性需求：对系统的操作的一种约束，与系统的功能没有关系。

例如，用户必须能够买到票以及用户必须能够查到价目信 息就属于功能需求。而用户必须在1秒钟内得到反馈信息 和用于接口的颜色应与公司LOG的颜色一致则属于非功能 需求。

记号、方法，方法学

记号：模型规则的图示或者文本集合。 UML：面向对象模型的记号。

软件开发活动

需求获取：用例图表示系统

在需求获取过程中，客户和开发者定义了系统的目标。这一活动的结果就是用参与者(actor)和用例(use case) 来描述系统。参与者代表与系统相互作用的外部实体. 用例是事件的总序列.

简化手表功能的UML用例图。手表用户WatchUser参与者可以 查看手表上的时间(使用读时间用例ReadTime)，也可以设置手表上的时 间(使用设置时间用例SetTime)。然而，只有手表维修工 WatchRepairPerson参与者可以更换手表中的电池(使用ChangeBattery更 换电池用例)。参与者图示表示成火柴棍小人，用例图示使用椭圆，系统 边界是指将用例包含在内的矩形盒子的边界。

需求获取的实例：

用例名：购买单程车票PurchaseOneWayTicket
参与者：由旅客Traveler启动
事件流：1-旅客Traveler选择始发站和目的站。2-售票系统TicketDistributor显示车票价格。3-旅客Traveler投入不少于车票价格的钱。4-售票系统TicketDistributor给旅客Traveler输出指定的车票，并找回多于的零钱。
入口条件：旅客Traveler站在始发车站或其它车站的售票系前面。
出口条件：旅客Traveler拿到有效车票和找回的零钱
质量需求：如果交易持续了1分钟后，没有产生响应结果，则售票系统 TicketDistributor退出所投入的钱。

需求分析：注明了属性，操作，关联的系统模型。该系统模型描述系统的对象模型（简陋的UML类图）和动态模型（UML顺序图）。

动态模型

售票系统TicketDistributor的一个动态模型(UML顺序图)。该图 描述了在购买单程车票PurchaseOneWayTicket用例和参与该用例
2023年5月17日8时53分 41 的对象过程中，参与者和系统之间的交互。

对象模型：

个售票系统TicketDistributor的对象模型(UML类图)。在购买单 程车票PurchaseOneWayTicket用例中，一位旅客Traveler初始化交易， 交易的结果将是一张车票Ticket，一张只在规定区域Zone内有效的车票Ticket。在交易Transaction过程中，系统通过计数投入的硬币Coin和纸币Bill来跟踪余额Balance。

系统设计:得到分解后的（被分解的子系统UML类图），和表示系统硬件/软件映射的（部署图）

选择构建系统放入策略：例如系统运行的硬件/软件平台，持久数据管理策略，存储控制策略。分析和系统设计都会产生在建系统的模型，分析期间产生的模型是客户能理解的实体。系统设计要处理的是一个非常精练的模型，它包括很多客户理解不了(也不感兴趣) 但开发者必须理解的实体

售票系统TicketDistributor的一个子系统分解(UML类图、包代表子 系统，带箭头线条表示依存性)。旅客接口TravelerInterface子系统负责从旅客处收集输入数据以及提供反馈信息(即显示车票价格，找 零)。本地价目表LocalTariff子系统根据本地数据库计算不同区间的车票价格。中央价目表CentralTariff子系统，位于中央计算机，维护价目表数据库的一个参考副本。更新Updater子系统负责在票价变动时， 通过网络更新每台售票系统TicketDistributor上的局域数据库

对象设计：得到（详细的UML），模型备注对每个元素的约束的精确描述。

实现阶段：实现每个对象的属性和方法以及集成所有对象一起运作。详细的对象设计到到一个完整的可编译的源代码文件集合。

测试：单元测试-对象设计（在对象设计时开始规划）/集成测试-系统设计（在系统设计时考虑测试计划）/系统测试-需求模型（在需求获取和分析阶段规划）

Part-2-1

用例图、类图、交互图、状态机和活动图 构件图和部署

系统开发-功能模型（用例模型）/对象模型/动态模型

功能模型（用例模型）：从用户观点出发，使用UML中的用例图描述系统功能

对象模型：使用UML中的类图表示对象模型，类图使用对象、类、属性、操作和关联等描述了系统的结构。

在需求分析阶段：分析对象模型作为对象模型，描述了与系统相关的应用概念。

在系统设计阶段：对象模型被求精为系统设计对象模型，该模型包括子系统接口的描述。

在对象设计期间：对象模型被求精为对象设计模型，该模型包括解答域结构对象的细节描述。

动态模型：UML中使用交互图、状态机图和活动图

状态机图:使用了单一对象的状态和这些状态之间可能存在的迁移行为。顺序图将关注点放在对象之间的信息交换上，其结果是由参与者创建了外部事件。状态机将关注点放在状态之间的迁移上，其结果是由一个独立对象产生了外部事件。

交互图:采用一组对象之间发生的交互消息序列描述了行为。顺序图是交互图的一种特殊形式。参与者：其作用是初始化用例，也成为启动用例。带标号的箭头：一个参与者或一个对象向另一个对象发送的激励或者事件。

活动图:用控制流（控制流说明了操作发生的次序）和数据流（对象之间完成操作时所交换的内容。）描述了行为。利用活动描述了一个系统的行为。活动是表示操作集合执行的建模元素。一个活动执行完成后通过可得到的对象或者通过外部事件，可以触发另一活动的执行。活动图也可以描述控制流，也可以描述数据流。

Part-2-2

面向对象建模的过程：

解答域(solution domain)：所有可能系统的建模空间。对解答域的建模表示了开发过程中的系统设计和对象设计 活动。解答域模型与应用域相比，其表现特点是内容更加丰富且更易变化
面向对象分析关心的是应用域的建模
面向对象设计关心的是解答域的建模。
在这两个方面的建模活动中，使用了相同的表示(如类和对象)

系统开发的主要关注应用系统的三个不同模型:

动态模型：交互图（时序图/协作图）「采用一组对象之间发生的交互消息序列描述了行为」状态机图「单一对象的状态以及这些状态之间存在的迁移行为」，活动图「控制流和数据流描述了行为」对象模型：类型表示对象模型，使用对象，属性，关联描述系统结构功能模型：用例图描述系统功能

用例图-通信/包含/扩展/继承

用例在需求获取和分析过程中表示系统功能。参与者在系统边界之外，而用例在该系统的边界之内。

通信关系：通信关系采用连接参与者记号和用例记号。带箭头的实线，箭头指向用例。 包含关系：通过使用不同用例标识模型的共性。虚线箭+<<include>>箭头指向被包含的用例. 扩展关系：对其它用例增加事件的办法，来扩展一个用例。继承关系/泛化关系：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。带空心箭头的实线，箭头指向被继承的用例，

类图

类图用来描述系统的结构。类图使用了对象、类、属性、操作和关联等元素描述系统。UML允许单方向关联

聚集(一种描述组合的关系)
限定是使用关键字约简重数的一项技术.
交互图描述了一组交互对象之间的通信模式。一个对象通过发送消息与其他对象进行交互。一个对象接收的消息触发了一个方法的执行，这一方法接着又向另一对象发送消息。可通过消息传递，变量被限制在接收消息对象的执行方法的参数上。交互图分为顺序图（描述了参与交互的对象）或协作图（交互以及参加交互的对象） 。通过消息传递，变量被限制在接收消息对象的执行方法的参数

交互图

采用一组对象之间发生的交互消息序列描述了行为.

交互图通常用于将系统动态行为形式化，将对象之间的通信可视化。表示了发生在这些对象之间的交互。

我们将包含在用例中的对象称为参与对象。

参与者：初始化用例。带标号的箭头：一个参与者或一个对象向另一个对象发送的激励或者事件。

状态机图

单一对象的状态以及这些状态之间存在的迁移行为

顺序图将关注点放在对象之间的信息交换上，其结果是由参与者创建了外部事件. 状态机将关注点放在状态之间的迁移上，其结果是由一个独立对象产生了外部事件

活动图

活动图利用活动描述了一个系统的行为.活动图也可以描述控制流，也可以描述数据流.控制流说明了操作发生的次序,数据流说明了对象之间完成操作时所交换的内容。一个活动执行完成后通过可得到的对象或者通过外部事件，可以触发另一活动的执行。

活动/决策/控制流
活动可以被分类并放进不同的「泳道」也称 为活动划分。

UML的扩展机制

版型(stereotype)

版型是一种扩展机制，以允许开发者对UML中的元素进行分类。

约束(constraints)

约束是一个附着在UML模型元素上的限制其语义的规则，如前置条件、后置条件.

Part4 -需求获取

需求获取的是系统必须具有的特征，是客户可接受的、系统必须满足的约束。需求工程的目标是定义所构造系统应该满足的需求 需求工程：1.需求获取「导出用户可理解的系统规格说明」2.需求分析「定义开发者可无二义性解释的分析模型。」

场景：使用了用户和系统之间的一系列交互，描述了一个系统实例

一个用例是描述一类场景的抽象场景和用例两者均用自然语言描述。

步骤：1-抽象场景。2-确认系统描述 3-确认功能性需求、非功能需求、用例和场景

需求获取：1.关注系统目标的描述『标识了一个问题域，给出了解决这一问题的系统定义』。2 需求规格说明用自然语言来书写，而分析模型通常用形式化或半形式化方式表示出来。

需求获取和分析仅将关注点放在用户对系统的看法上。例如，系统功能表示了用户和系统之间的交互、或者表示了系统可检测和处理的错误，或者表示了作为需求部分的系统功能的环境条件。系统结构表示了构造系统所选择的实现技术，系统设计表示了开发方法，这些内容以及对用户而言不可见的其它方面，均不是需求规格说明的组成部分

需求获取概念

功能性需求：功能需求描述了系统与其独立于系统实现的环境之间的交互非功能性需求描述了不直接关联到系统功能行为的系统的方方面面「可用性、可靠性、性能、可支持性。」可用性：可用性是一种用户可以学会的操作、输入准备、解释一个系统或者构件输出的情况。可靠性：系统或构件在给定时间内以及指定条件下完成其要求功能的能力。性能：要考虑系统的定量属性「对用户输入而言，系统响应的快慢程度、吞吐量(在一个指定的时间量内系统可完成的工作量)、有效性(当提出使用要求时，系统或构件的可操作性和可访问性程度)和准确性」可支持性：关注在进行部署后去改变系统的情况。非功能性需求还包括：实现需求/接口需求/操作需求/打包需求/合法需求实现需求：特定工具、程序设计语言和硬件平台的使用。接口需求：接口需求是外部系统强制性的约束，包括合法系统和交互格式。操作需求：管理员和系统操作设定方面的约束。打包需求：是系统实际提交方面的约束(如为了软件设定而说明的安装介质约束)。合法需求所关心的是使用许可证、规则和认证等方面的问题。

需求确认的概念

需求确认包括检查需求是否是完全的、一致的、无二义性的和正确的。完全的：涉及系统的所有可能场景均已描述一致性的：规格说明与其本身无矛盾无二义性的：不可以存在有两种或多种解释正确的：满足客户和开发者双方要求。

需求规格的概念

需求规格说明至少应该具有的三个属性是:可现实性、可确认性和可追踪性。可现实的：系统可在约束下可以实现。可确认的：系统构建起来后，应该可以设计出能重复执行的接收测试。可追踪的：支持这些配置之间的自顶向下或者自底向上的两个方面的一致性审查和确认。每一个系统功能可逆向追踪到其对应的需求集合上。

应用：1-开发测试用例的时候：可追踪性使得测试者能够评价测试用例的覆盖情况，即标识出哪些需求被测试到了，哪些需求未被测试。2-评价改变的时候：使得可以标识出改变将影响到的有关构件和系统功能

需求获取的活动

1-标识参与者：定义了系统边界并从开发者要考虑的系统中找出所有的观察点。系统边界定义后：区别参与者和这类系统构件究竟是对象还是子系统。子系统和对象在系统边界之内;它们是内部的。参与者是在系统边界之外的;它们是外部的。

2-标识场景：一个场景是一个用例的实例，即对一个给定功能而言，一个用例可以说明这一给定功能下的所有可能场景。

标识场景的例子：
场景名称 仓库着火
参与者实例 Bob，Alice:现场工作人员
事件流 1. Bob正驾驶着他的巡逻车在主要街道上巡逻，他发现一个仓库冒出了黑烟。于是Alice，即Bob的同事，从自己的FRIEND膝 上电脑上激活“紧急情况报告”功能。2. Alice输入建筑物所在的地址，简要描述了其位置(即西北 角)和紧急程度。考虑到这一地区相对比较繁华，因此除了 消防队外，Alice还请求了几个医疗队前来。Alice在确定输入后，等待对方回答。
3. John是调度者，他通过工作站发出来的嘟嘟声音发觉了这一
紧急情况。John查阅了Alice的邮件信息，并对其报告进行了如下回 复。首先John指派了一个消防队和两个医疗队赶到出事地点，接着他 将相关队伍的到达时间(ETA)通报给了Alice。
4. Alice收到了回复和相关队伍预计到达的时间。

3-标识用例

标识用例的例子：
用例名称：  报告紧急情况ReportEmergency 
参与者：  由现场工作人员FieldOfficer启动 与调度者调度者Dispatcher联络
事件流：
1.现场工作人员FieldOfficer激活其终端上“报告紧急情况”的功能。 2.FRIEND系统通过向给现场工作人员提交一张表格，对来自现场工作人员的申请做出反应。 3.现场工作人员FieldOfficer填好表格:选择紧急级别、类型、位置和简单情况描述。现场工
作人员FieldOfficer还需要描述紧急情况可能造成的后果。一旦现场工作人员FieldOfficer填
写完毕，就提交表格，以通知调度者Dispatcher。
4. FRIEND接收到表格后，就通知调度者Dispatcher。
5. 调度者Dispatcher检查所收到的提交信息，并通过调用打开事件用例OpenIncident在数据库
中创建一个事件Incident。调度者Dispatcher在收到该紧急报告后选择响应并确认。 6. FRIEND系统显示确认信息和对现场工作人员FieldOfficer选择的响应。

入口条件：现场工作人员FieldOfficer登陆进入FRIEND。
出口条件：现场工作人员FieldOfficer收到确认信息并选择来调度者Dispatcher的响应，或者现场工作人员FieldOfficer收到一条解释信息，以说明为何该事务不必处理。  现场工作人员FieldOfficer的报告要在30秒钟内答复。
质量需求： 选择响应要在调度者Dispatcher发送请求后30秒钟内到达。

用例的名字应该是一个动词短语，以说明参与者将完成什么功能。动词短语“Report Emergency(报告紧急情况)”表明一个参与者试图向系统(即向调度者 Dispatcher)报告紧急情况。

4-求精用例

使用扩展关系来区分异常事件流和公共事件流。我们使用包括关系，以减少用例之间的冗余.

5-标识参与者和用例之间的关系

6-标识初始的分析对象

如果两个对象共享同一个名字但没有对应相同的概念,则其中的一个概念或者两个概念必须进行重新命名.

7-标识非功能性需求

可用性（健壮性，安全性，保密性）/可靠性/性能/支持性

可用性包括：

系统应该具有的可靠性、可用性和健壮性是什么? 重启系统在失效事件中是否是可以接收的? 有多少数据系统可以释放?系统怎样处理异常?
系统的安全需求是什么? 系统的保密要求是什么?

性能：

系统应该怎样进行响应?
有无用户任务要求时间关键?
系统应该支持的并发用户有多少?
对于一个可比较的系统而言，典型的数据存 储量有多大?
用户所能够接收的最坏延迟是什么?

支持性:

系统可预见的扩充是什么?
谁维护该系统?
是否有计划，考虑系统支持不同的软件和硬件环境?

实现：

硬件平台的约束是什么?
管理团队制定的约束是什么?
测试团队制定的约束是什么?

8.追踪性维护

这一能力包括跟踪需求从哪里来(例如，谁组织需求，这一需求要 解决哪一个客户的需要)，需求分到系统的哪一部 分去，以及对项目的影响例如，哪一个构件实现了该需求，哪一个测试检查了其实现.

追踪性使得开发者看到的系统是完全的，使得测试 者看到的系统是否与其需求相符合，使得设计者记 录了系统内部的机理，以及是的维护者评价变化带来的影响。

需求获取的结果

需求分析文档 1.1系统目标1.2系统范围1.3项目的目标和成功的标准1.4定义，首字母缩写和缩写词 2.当前的系统 3.建议的系统：3.1 概述 3.2功能性需求 3.3非功能性需求：3.3.1 可用性，3.3.2可靠性 3.3.3 性能 3.3.4可支持性 3.3.5 实现性 3.3.6 接口 3.3.7 打包 3.3.8 合法性 3.4 系统模型 3.4.1 场景，3.3.2用例模型 3.3.3 对象模型 3.3.4动态模型 3.3.5 实现性 3.3.6 接口 3.3.7 打包 3.3.8 合法性

Part5-分析

需求获取和分析之间的关系表现为：迭代和递增的活动

与需求获取活动的不同之处是，在分析活动中，系统分析员将关注点放在怎样将从用户处抽取的需求规格说明进行形式化上面。形式化导致：新洞察，需求错误。

分析的概念

分析模型由三个独立模型构成：1.用用例和场景表示的功能模型2.用类和对象图表示的分析对象模型.3.用状态图和顺序图表示的动态模型等。

分析对象模型和动态模型

分析对象模型是分析模型的一部分:关注点放在系统、系统特征和系统关系操纵这些单一概念上。 UML类图描述的分析对象模型，包括类、属性和操作。动态模型将注意点放在系统的行为上。顺序图表示单一用例期间一组对象之间的交互。状态图：单一对象(或者一组非常紧密处理对象)的行为。状态图用于将责任分配给某一类，并且在这一过程中标识出新的类、关联和属性，并将之加入分析对象模型中

实体/边界/控制对象

实体对象表示系统将跟踪的持久信息。 边界对象表示参与者与系统之间的交互 控制对象负责实现用例。

例如，在具有两个按钮的2Bwatch实例中，年(Year)、 月(Month)和日(Day)是实体对象;按钮Button和液 晶显示器LCDDisplay是边界对象;改变对数据的控制 ChangeDateControl，则是控制对象，以表示通过按下组 合按钮改变日期的活动。

分析的活动-从用例到对象

1-标识实体对象
2-标识边界对象
3-标识控制对象
4-使用顺序图将用例映射成对象
5-使用CRC卡建模对象之间的交互
6-标识关联
7-标识聚集
8-标识属性
9-建模单一对象的状态依赖的行为
10-建模对象之间的继承关系
11-分析模型评审
12-分析小结

自然语言分析方法[Abbott，1983]，可得到一个靠直觉的获得的具有各种不同词汇成分的启发式集合

语言 成分模型构件 实例
专有名词 实例  Alice
动词  操作 创建/提交

标识实体对象

标识边界对象

标识用户需要启动用例的用户接口控制(如ReportEmergencyButton)。
标识用户需要键入数据到系统的表格(如EmergencyReportFrom)
标识系统用于响应用户的通知和消息(如AcknowledgementNotice)。

标识控制对象

控制对象负责协调边界对象和实体对象。

**报告紧急情况控制** 现场工作人员通过基站FieldOfficerStation(一种移动设备) 中的管理紧急情况报告ReportEmergency提交报告的功能。当现场工作人员 FieldOfficer选中“报告紧急情况Report Emergency”按钮时，该对象被创建。 然后，由该对象创建报告紧急情况表格ReportEmergencyForm，并将其提交 给当现场工作人员FieldOfficer。在当现场工作人员FieldOfficer填表并提交表 格后，该对象收集来自表格的信息，并将其发送给调度者Dispatcher。接着 该控制对象等待一个来自调度者基站DispatcherStation(一种台式工作站) 的答复。当答复收到后，报告紧急情况控制对象ReportEmergencyControl创 建一个确认通知AcknowledgmentNotice，并将该确认通知发送给当现场工作 人员FieldOfficer。

**管理紧急情况** 通过调度者基站DispatcherStation管理报告紧急情况 ReportEmergency的提交报告功能。当触发一个报告紧急情况 ReportEmergency时，该对象被创建。接着，该对象创建一个表格事件并将 该事件发送给调度者Dispatcher。一旦调度者Dispatcher创建了一个事件 Incident ，配置了相关资源，并提交了一个答复后，管理报告紧急情况控制 ManageReportEmergencyControl就会将这一答复发送给现场工作人员基站。

顺序图将用例映射成对象

顺序图将用例与对象联系在一起。
顺序图代表了另一个观察视角，使得系统分析员能够发现规格说明中遗漏的对象或界限不明的领域。

顺序图的第一栏对应着激活该用例的参与者; 顺序图的第二栏表示边界对象第三栏是管理其余用例的控制对象。通过边界对象启动用例以创建控制对象。通过控制对象创建边界对象。通过控制对象和边界对象访问实体对象。实体对象从来不会访问边界对象和控制对象，实体对象从来不会访问边界对象和控制对象

使用CRC卡（CRC是类、责任和协作的缩写）建模对象之间的交互

类的名字标识在CRC卡的顶端，其责任标识在左栏中;为了完成其责任，所需要(协作)的类名字标识在右栏中

标识关联

顺序图允许表示对象之间的交互类图允许系描述对象之间的相互依赖。

关联
EmergencyReport类与 FieldOfficer类之间的关联实例。
EmergencyReport 一条直线连接 FieldOfficer，直线上写着（write）

组合聚集

例如，一个救火站FireStation包括多个救火枪FireFighters，多辆救火车FireEngines，多辆救护车Ambulances以及指挥车LeadCar。
一个聚集表示为带有钻石符号的关联，其中的钻石符号靠近“整体”
的一端。

实心钻石符号表示。组合聚集说明了部分存在依赖于整体。例如，省 Country总恰好是国家State的一个部分，而城镇TownShip总恰好是一个省Country的部分。

共享聚集

例如，尽管救火车FireEngine在一个时间至多是一个救 火站FireStation的资产，但救火车FireEngine在其生命周期中还可以 再分配给不同的救火站FireStation使用，这样就改变了所属关系。

空心钻石符号的关联表示了共享聚集关系，表示整体和部分可以独立地存在

标识属性

在标识对象的属性时，仅考虑与系统相关的属性。 例如，每一个现场工作人员FieldOfficer都具有一个社会安全号，但该号与紧急信息系统无关。事实上，现场工作人员FieldOfficer可使用徽章号标识，该号表示为徽章编号BadgeNumber性质

建模单一对象的状态相关的行为

Incident的UML状态图。

建模对象之间的继承关系

分析模型评审

分析对象模型是使用增量和迭代的方法来构建的. 评审的目标是，确定需求规格说明是正确的、完全的、一致性的和可实现的，以及是否是可确认的。

对实体对象的分类，用户是否能够理解?
- 抽象类是否对应到用户层上的概念?
- 是否所有的描述均利用了用户定义?
- 是否所有实体对象和边界对象均使用了有意义的 名词短语进行了命名?
- 是否所有用例和控制对象均使用了有意义的动词 短语进行了命名?
- 是否所有的错误用例均已经描述和处理?

对每一个对象:是否有用例需要之?创建该对象的用例是 谁?修改该对象的用例是谁?删除该对象的用例是谁?该对象可以被一个边界对象访问吗?
- 对每一种属性:该属性何时设定?该属性的类型是什么? 该属性应该进行修饰吗?
- 对每一种关联:该关联何时被遍历(访问)到?为何如此 选择该关联的多样性?该关联可以使用一对一、一对多和
多对多来描述吗?
- 对每一个控制对象:该控制对象具有必要的关联以访问到 应用中的对象吗?
- 是否有多个类或用例具有相同的名字?
- 具有相似名字的实体(如用例、类和属性) 注明了相似的概念了吗?
- 在相同的泛化层次中，是否存在相似属性和 关联的对象?

在该系统中是否出现任何新的特征?是否有 任何针对这些新特征而进行的构造研究或 建构原型系统的活动，以确保其实现上的 可行性?
- 性能要求和可靠性要求是否已经满足?运行 在所选择硬件上的任何原型的需求是否可以确认?

练习题

https://wenku.baidu.com/view/609d182a7375a417866f8fb6?aggId=3e12f2e20ba1284ac850ad02de80d4d8d15a01bb&fr=catalogMain_text_ernie_recall_backup_new:wk_recommend_main4

https://wenku.baidu.com/view/6b7f0d627fd5360cba1adbf7?aggId=d36b1b40b307e87101f69655&fr=catalogMain_text_ernie_recall_v1%3Awk_recommend_main4&_wkts_=1685354780425&wkQuery=%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E6%9C%9F%E6%9C%AB

https://wenku.baidu.com/view/20a343edf8c75fbfc77db2c7.html?fr=income3-doc-search&_wkts_=1685356832770&wkQuery=%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E5%88%86%E6%9E%90%E5%92%8C%E8%AE%BE%E8%AE%A1%E7%AE%80%E7%AD%94%E9%A2%98

ATAM则主要在于为利益相关者提供对系统的推荐方案，以满足其需求并优化体系结构。

ARID包括以下四个阶段：需求定义、体系结构设计、评估和迭代。在该题中要考虑该购物平台的功能特点，并确定适合该平台的质量属性。根据质量属性，设计不同的架构方案，并对其进行评估和比较。最后确定最适合该购物平台的体系结构方案，并建立一个反馈机制确保体系结构的持续改进。回答：

首先，根据购物平台的功能特点，我们可以确定一些适合该平台的质量属性，比如性能、可扩展性、安全性、可维护性等。

在ARID的第一个阶段—需求定义阶段，我们会着重分析这些质量属性并确定需求。例如我们需要考虑：

性能：用户访问网站时，页面应该快速加载和相应，而且用户同时使用大量资源时，应用程序能够正常工作。可扩展性：当用户数量增加时，购物平台应该能够无缝地扩展，而不会降低性能。安全性：该购物平台将处理大量的用户个人信息和交易数据，因此必须采取适当的安全措施，以防止任何类型的数据泄露或黑客攻击。可维护性：购物平台需要经常更新和修复，因此代码应该易于编辑和修改，同时对现有的功能没有不良影响。在第二个阶段——体系结构设计阶段，我们要根据这些质量属性设计不同的架构方案。例如，我们可以考虑以下几个架构：

分布式架构：这是一种将系统分成多个部分并分布在不同服务器上的架构，可以提高可扩展性和性能。微服务架构：这是一种将系统中的不同功能部分化为互相独立且自治的微服务，并通过API进行通信的架构，可以提高可维护性、可伸缩性和灵活性。事件驱动架构：这是一种基于事件进行通信和交互的架构，可以实现松散耦合组件之间的通信，并提高系统的灵活性和可扩展性。在第三个阶段——评估阶段，我们可以使用ATAM（ Architecture Tradeoff Analysis Method）等方法来评估这些架构方案，从而确定哪种架构能够最好地满足我们的需求和质量属性。

最后，在第四个阶段——迭代阶段，我们要建立一个反馈机制来持续改进体系结构，并根据用户反馈和分析结果进行不断优化。例如，如果应用程序出现性能瓶颈，则可以通过缓存、负载均衡等技术来提高性能。

简答题

1.什么是面向对象方法？面向对象的基本原则主要有哪些？答：面向对象方法是一种运用对象、类、继承、封装、聚合、关联、消息、多态性等概念来构造系统的软件开发方法。面向对象方法的解决问题的思路是从现实世界中的客观对象（如人和事物）入手，尽量运用人类的自然思维方式来构造软件系统，这与传统的结构化方法从功能入手和信息工程化方法从信息入手是不一样的。

2.面向对象的基本思想是什么？答：「1」从现实世界中客观存在的事物出发米建立软件系统，强调直接以问题域＜现实世界）中的事物为中心来思考问题、认识问题，并根据这些事物的本质特征，把它们抽象地表示为系统中的对象，作为系统的基本构成单位。这可以使系统直接映射问题域，保持问题域中事物及其相互关系的本来面貌（对象）「2」用对象的属性表示事物的性质；用对象的操作表示事物的行为。（属性与操作）「3」对象的属性与操作结合为一体，成为一个独立的、不可分的实体，对外屏蔽其内部细节。（对象的封装）「4」对事物进行分类。把具有相同属性和相同操作的对象归为一类，类是这些对象的抽象描述，每个对象是它的类的一个实例。（分类）「5」复杂的对象可以用简单的对象作为其构成部分。（聚合〕「6」通过在不同程度上运用抽象的原则,可以得到较一般的类和较特殊的类。特殊类继承一般类的属性与操作，从而简化系统的构造过程及其文档。（继承）「7」对象之问通过消息进行通讯，以实现对象之间的动态联系。（消息）「8」通过关联表示类(一组对象)之间的静态关系。（关联）

2．与传统开发方法比，面向对象方法有什么优点？答：面向对象方法的解决问题的思路是从现实世界中的客观对象（如人和事物）入手，尽量运用人类的自然思维方式来构造软件系统，这与传统的结构化方法从功能入手和信息工程化方法从信息入手是不一样的。与传统方法相比，面向对象的方法主要优点有：「1」从认识论的角度可以看出，面向对象方法改变了人们认识世界的方式；「2」语言的发展-鸿沟变窄：「3」面向对象方法使得从问题域到计算机间的鸿沟变窄；「4」面向对象方法有助于软件的维护与复用；「5」把易变的数据结构和部分功能封装在对象内并加以隐藏，一是保证了对象行为的可靠性；二是对它们的修改并不会影响其他的对象，有利于维护，对需求变化有较强的适应性。「6」封装性和继承性有利于复用对象。把对象的属性和操作拥鄉在一起，提高了对象（作为模块）的内聚性，减少了与其他对象的男合，这为复用对象提供了可能性和方便性。在继承结构中，特殊类对一般类的继承.

3.什么是面向对象？答：面向对象不仅是以些具体的软件开发技术与策略，而且以一套关于如何看待软件系统与现实世界的关系，以什么观点来研究问题并进行求解，以及如何进行系统构造的软件方法学。

4.软件开发方法学的基本方法有哪些？答：面向对象方法学。UML RUP，XP

5.为什么需要 OOA、OOD。

答： OOA就是运用面向对象的方法进行需求分析，OOA 加强了对问题域和系统责任的理解，有利于人员之间的交流，对需求变化的适应性较强，很好的支特软件复用。 OOD就是运用面向对象的方法进行系统设计，0OD.符合人们习惯的思维方法，便于分解大型的复杂多变的问题：易于软件的维护和功能的增减：可重用性好；与可视化技术相结合，改善了工作界面。

6.从概念层次、规格层次、实现层次三个角度如何理解对象的概念？

答：从概念层次来看，一个对象就是一系列的责任；从规格层次来看，一个对象是一系列可以被其他对象或该对象自己调用的方法：从实现层次来看，一个对象是一些代码和数据。

Tags: 软件工程