软件工程对象结构模型
软件工程(简答题)
1、简述结构化范型和面向对象范型的要点，并分析它们的优缺点。
答：结构化范型要点：结构化范型也称生命周期方法学，属于传统方法学。
传统的软件开发方法大部分采用瀑布模型。
这种模型要求每一阶段都以前一阶段形成的文档为基础完成工作。
每一阶段将要完成时，都要求开发人员进行验证或确认。
瀑布模型要求在软件产品生成之前对用户需求进行尽可能精确的、完全的刻画。
但要完成这种任务相当困难。
优点：把软件生命周期划分成基干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发过程的困难程度.缺点:当软件规模庞大时，或者对软件的需求是模糊的或会承受时间而变化时，开发出的软件往往不成功；而且维护起来仍然很困难。
面向对象范型四个要点：（1）面向对象的软件系统是由对象组成的，软件中的任何元素都是对象，复杂的软件对象由简单的软件对象组合而成。
（2）所有对象划分成各种对象类，每个对象都定义了一组数据和一组方法。
（3）按照子类（派生类）和父类（基类）的关系，把若干个对象类组成一个层次结构的系统（类等级）。
在派生类中对某些特性又做了重新描述，则在派生类中的这些特性将以新描述为准，也就是说，低层的特性将屏蔽高层的同名特性。
（4）对象彼此之间仅能通过传递消息互相联系。
面向对象范型主要优点（1）按照人类习惯的思维方法，对软件开发过程所有阶段进行综合考虑；（2）软件生存期各阶段所使用的方法、技术具有高度的连续性；（3）软件开发各个阶段有机集成，有利于系统的稳定性】6、非渐增式测试与渐增式测试有什么区别？答：【区别：1、非渐增式测试方法把单元测试和集成测试分成两个不同的阶段，前一阶段完成模块的单元测试，后一阶段完成集成测试。
而渐增式测试往往把单元测试与集成测试和在一起，同时完成。
2、非渐增式需要更多的工作量，因为每个模块都需要驱动模块和桩模块，而渐增式利用已测试过的模块作为驱动模块或桩模块，因此工作量较少。
渐增式可以较早的发现接口之间的错误，非渐增式最后组装是才发现。
软件工程 第八章 面向对象的设计方法
第八章面向对象的设计方法本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。
如第五章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
为完成这一转换过程，设计人员必须处理以下任务：（1）针对分析模型中的用例，设计实现方案。
实现方案用UML交互图表示。
（2）设计技术支撑设施。
在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。
这些设施本身并非业务需求的一部分，但却为多种业务需求的实现提供公共服务。
例如，数据的持久存储服务、安全控制服务和远程访问服务等。
在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。
（3）设计用户界面。
（4）针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。
此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序设计的基础和依据的详尽类图。
面向对象的软件设计过程如图8-1-1所示。
图8-1-1 面向对象的软件设计过程第一节设计用例实现方案UML 的交互图（顺序图、协作图）适于用例实现方案的表示。
因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。
该设计方法包含如下3个步骤：（1）提取边界类、实体类和控制类；（2）构造交互图；（3）根据交互图精华类图。
一、顺序图顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。
在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。
顺序图中的对象一般以“对象名：类名”的方式标识，但也可以仅采用缩写形式“对象名”或者“：类名”。
《实用软件工程》第9章 面向对象设计
• 信息隐藏：对于类而言，其内部信息如属性的表示方法和操作的实现算法，对 外界是隐藏的。外界通过有限的接口来访问类的内部信息。
17
9.3.2 面向对象设计的原则
• 低耦合：在面向对象设计中，耦合主要指对象之间相互关联的紧密程度，低耦 合有利于降低一个模块改变对其他模块的影响。
• 高内聚：内聚与耦合密切相关，低耦合往往意味着高内聚，高内聚有助于提高 系统独立性。
但随着需求理解的加深，以及对系统认识程度的逐步 提高，设计人员还要对模型进行修正和完善。 • 设计任务管理子系统包括确定任务，分配任务，还包 括权衡一致性、成本、性能等因素以及未来可扩充性。 • 设计数据管理子系统，需要设计数据格式以及相应的 服务，设计数据格式的方法与所用的数据存储管理模 式密切相关，不同数据存储管理模式时，属性和服务 的设计方法是不同的。
9.2 面向对象设计与面向对象分析的关系
• 设计阶段的任务是及时把分析阶段得到的需求转变成符合各项要求的 系统实现方案。与传统的软件工程方法不同的是，面向对象的方法不强调 需求分析和软件设计的严格区分。实际上，面向对象的需求分析和面向对 象的设计活动是一个反复迭代的过程，从分析到设计的过渡，是一个逐渐 扩充、细化和完善分析阶段所得到的各种模型的过程。严格的意义上来讲， 从面向对象分析到面向对象设计不存在转换问题，而是同一种表示方法在 不同范围的运用。面向对象设计也不仅仅是对面向对象分析模型进行细化。
• （2）人机交互子系统包括有效的人机交互所需的显示和输入，这些类在很大程度上 依赖于所用的图形用户界面环境，例如Windows、Delphi、C++，而且可能包括“窗 口”、“菜单”、“滚动条”、“按钮”等针对项目的特殊类。
25
9.5.1 系统分解
软件体系结构4 1模型实例
第七部分设备管理1.功能描述：设备管理功能主要包括设备信息的编辑（增加、删除、修改）。
1.1.设备信息包括设备的位置信息、名称、状态。
1.2.设备信息的编辑：支持对设备信息的编辑（增加、删除、修改）。
2.内容概述：运用4+1视图模型，从5种视图角度，进行分析设计。
2.1场景视图（Use case）使用user case图设计系统的各个场景。
2.2逻辑（功能）视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
2.3开发（模块）视图（Development View），描述了在开发环境中软件的静态组织结构。
2.4物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
2.5过程视图（Process View），捕捉设计的并发和同步特征。
4+1视图综述：3.设计详情：3.1场景视图(Scenarios)：参与者与用例构成场景视图，对设备的设置从修改，删除，增加三方面驱动。
如图1：图1在设计场景视图时，对包含（include）和扩展(extend)的应用需要仔细琢磨，刚开始并不知道每种的应用范围，看了网上的例子，和以前软件工程的书，大概了解包含的概念是一些必然发生的用例，然而扩展是在特殊情况的时候才可能发生的非正常情况。
我觉得一个小小的箭头也许在现在的项目作业中并不重要，但是在今后的学习工作中它会从某种程度上决定项目的成败，并体现出个人对工作和生活的认真态度，所以，大学课程的好处就是允许我们在实践和失败中汲取教训，总结经验。
在这部分，有同学提出了质疑，认为需要具体细分一下，如图2：图2在这里，也是得到其他同学的启发，场景视图必须要具体细分，它注重功能的概念，细分的过程可以放在逻辑视图中，通过函数来具体实现。
在这部分，我还需要更深入的了解，在实际应用过程中不断摸索。
3.2逻辑视图（Logic View）：逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务。
面向对象的平面结构与软件工程生命周期模型的关系
软件从工程的角度讲有好几种生命周期模型。
所有的生命周期模型本质上都是功能导向的模型。
这与软件本身的功利性当然是分不开的。
毕竟不管从哪个角度看，它都仍然是一种人类工具。
而不是人类认识。
构建软件的过程本身也与科学基本上没什么关系。
软件是以“用”为其目的的。
软件开发范式本身与软件工程并不冲突。
开发范式在软件领域更象是一种哲学，代表了开发者的软件认识观或结构观。
而软件工程本身研究的则是作为一种过程的软件开发的学问。
一个是哲学，一个是过程，显然不是同一种知识，怎么可能会冲突呢？但是至少有一种周期模型与面向对象有点关系。
那就是迭代。
迭代模型的提出与面向对象在出发点上很可能是一样的，那就是两者都是为了应付“变化”。
面向对象通过模仿人类的知识系统结构达到了构建更稳定系统也即更能应付变化的系统的能力。
而迭代则是通过将需求切成几段也即“分而治之”的方法一点一点地得到了应付变化或者至少说，应付“认知”（其实非面向对象的开发范式中根本就不存在认知的概念。
这种不认知，即它的“认知”）的能力。
一个不采用面向对象作为其开发方法的迭代模型，自然将沿袭“功能分解”的传统哲学。
在这种哲学指导下开发出来的系统最终都是功能性系统。
象很多硬件一样。
是一种非常自然且普遍的系统构建方法。
事实上，这个世界上绝大多数的系统或者说科学，都是基于这样的思想构建起来的。
再说大一点，甚至整个人类文明的绝大部分也是基于这样的思想构建起来的。
从这个角度看，软件开发从一开始就非常自然地走向了功能性道路这一点并不足为奇。
倒是，如果它一开始不这么走，那才会让人觉得奇怪。
因为那不符合科学发展的自然趋势。
科学是功利的。
软件也必须是功利的。
科学的手段也是功利的。
软件的手段在今天，在大部分情况下，也是功利的。
好象无可厚非。
因为此，面向对象一直都是很难被接受的一样东西。
网上有文章说西方人从小就接受这样的思想，所以长大就变成很自然的东西。
这里不能同意。
因为其实西方人最擅长的并不是这么哲学的东西。
软件工程知识点总结
软件工程（简要知识点）一、. 软件过程五个模型对比（瀑布模型、快速原型、增量、螺旋、喷泉模型）二、可行性研究：1、任务：用最小的代价在尽可能短的时间内确定问题是否能够解决。
2、四个方面：技术、经济、操作可行性、法律3、数据流图四种成分：1、源点/终点2、处理3、数据存储4、数据流三、需求分析：1、任务：确定系统必须完成哪些工作，对目标系统提出完整、清晰、具体的要求。
2、结构化方法就是面向数据流自顶向下逐步求精进行需求分析的方法。
3、实体联系图：1、数据对象2、属性3、联系（1:1、1：N 、M:N ）四、总体设计：1.任务：回答“概括的说，系统应该如何实现”，用比较抽象概括的方式确定系统如何完成预定的任务，也就是说应该确定系统的物理配置方案，并且进而确定组成系统的每个程序结构。
2. 系统设计阶段（确定系统具体实施方案）、结构设计阶段（确定软件结构）3.模块独立：内聚和耦合4. 耦合表示一个软件结构内各个模块之间的互连程度，应尽量选用松散耦合的系统 问题定义（确定题目）可行性研究需求分析 概要设计详细设计编码和单元测试 综合测试系统设计 系统实现 软件定义 软件开发 运行维护：主要任务是使软件持久地满足用户的需要软件生命周期：5. 内聚(Cohesion): 一个模块内各元素结合的紧密程度6.面向数据流的设计方法：变换流和事务流五、详细设计：1.任务：确定应该怎样具体的实现所要求的系统，也就是说经过这个阶段的设计工作应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。
2.过程设计的工具（程序流程图、盒图、PAD图、判定表、判定树）七、测试：1、单元测试：又称模块测试。
每个程序模块完成一个相对独立的子功能，所以可以对该模块进行单独的测试。
由于每个模块都有清晰定义的功能，所以通常比较容易设计相应的测试方案，以检验每个模块的正确性。
2、集成测试：在单元测试完成后，要考虑将模块集成为系统的过程中可能出现的问题，例如，模块之间的通信和协调问题，所以在单元测试结束之后还要进行集成测试。
软件工程简答题整理
什么是软件危机，有哪些具体表现形式？其原因？答：软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
主要有以下表现形式：1、对软件开发成本和进度的估计常常很不准确 2、用户对“已完成的”软件系统不满意的现象经常发生 3、软件产品的质量往往靠不住 4、软件常常是不可维护的 5、软件通常没有合适的文档资料 6、软件成本在计算机系统总成本中所占的比例逐年上升 7、软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势原因：1、与软件本身特点有关2、与软件开发与维护的方法不正确有关什么是软件生存周期，有哪几个活动？比较模型软件生存周期是指一个软件该软件报废为止的整个时期。
软件生命周期由软件定义、软件开发和软件维护3个时期组成。
1问题定义，解决的问题是是什么；2可行性研究，问题是否有可行的解决办法；3需求分析，确定目标系统必须具备的功能；4总体设计，总体上解决问题，设计软件出层次结构图、5详细设计，具体实现，设计算法；6编码和单元测试，编程和单元测试；7综合测试，系统地设计测试用例；软件维护，修改软件满足用户需要。
瀑布模型：自上而下，相互衔接的固定次序，像瀑布逐级下落，有顺序性和依赖性，推迟实施，质量保证，严格要求输出文档，缺乏灵活性。
快速原型模型：能快速建立。
它所完成的功能往往是最终产品能完成的功能的一个子集，适合中小型，短周期的交互式系统。
增量模型：把软件产品作为一系列增量构件来设计、编码、集成和测试，能在较短的时间完成，有充裕的时间学习。
适合开发需求不明确设计方案有一定风险的软件项目。
螺旋模型：它是风险驱动的。
适合大型系统及软件的开发。
将瀑布模型与增量模型结合起来，喷泉模型：迭代和无缝连接简述软件测试的任务、目的与类型。
答：软件测试是一个为了寻找软件错误而运行程序的过程。
目的就是为了发现软件中的错误。
一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。
一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。
软件工程期末试题(部分答案)
EB登记已收款车票D受理收款 A 乘客C 车费计算一个班学生的平均成绩存储成绩 关闭文件并打 记录(3) 印平均成绩(4)计算某个科目的平均成绩创建新的成 绩记录(2) 读取科目和 初始化变量 sum 并打开文件(1) 成绩P 1图3 程序模块互连图3r5ts6uq42图 4 程序流程图a=0,b=1a++Fa<=100a++a>=20TFTa<=100Fa++图 5 程序流程图输入 A/B/C/DA>0 and B>0X=A-B X=A+BC>A and D<BY=C-D Y=C+D终止T学生成绩成绩报告核对后的成绩报告E3 E1成绩 审查 结果成绩管理系统课程 完成 通知E4D2学生成绩D1核对后的 成绩报告验证学生信息无效成绩 有效成绩2记录有效成绩课程完 成通知D5E3D45生成最终成绩单成绩单3记录无效成绩无效成 绩通知4生成成绩列表成绩审查结果成 绩 报 告列表 请求生成 成绩 成绩列表D3E4E1E21生成成 绩列表 请求无效成绩 通知 成绩 列表E2成 绩 单。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.1.4 关系
类(及其对象)之间的四种关系： 泛化（一般-特殊）—— 分类结构、继承机制 聚集（整体-部分）—— 组成关系、聚集机制 关联(实例连接)—— 静态联系 依赖—— 使用关系（行为依赖）
表示法
类1 类2
连接名称
多重性1 多重性2
一对一的连接： 1 一对多的连接： 1 多对多的连接： *
1 * *
实例
Order dataReceived isPrepaid number:String dispatch() close()
1 1
*
1 1
Customer name address CreditRating()
对象的精简
只有一个属性的对象： 班级 … … 1 1 班主任 姓名 … 班级 班主任姓名 … …
审查与筛选2
对象的精简 只有一个操作的对象：
输出设备 … … 1 1 格式转换器 … 文件格式转换 输出设备 … 文件格式转换 …
初始对象表
可能的类 用户 账户信息 学生档案 课程 选课信息 成绩信息 英文类名 User Account 简单描述 用户分三类：管理员、学生、教师 账户信息是系统需要管理的对象
对象结构模型
OOA模型
交互图表现完成某一项特定功能的一组对象 之间的详细交互；状态图描述了一个对象的 状态变迁。活动图描述了一个业务流程。 基本模型 （类图） 顺序图 状态图 活动图 对象层 特征层 关系层 详细说明 对模型中所有元素 进行详细说明 主题图 包图
对所有有关 的对象用对 象类表示 定义每个类 的属性与操 作 描述对象类 之间的关系
表示法
visibility operating-name(parameter-list): return-type {propertystring}
[可见性] 操作名称（参数表）：返回类型 {约束特性} 参数表：参数名：类型，… 返回类型：操作返回的结果类型。
Cumtomer
CheckOrder(order):Boolean 操作2 … 操作n
实例
对账户信息类的三层划分 界面层： user_add.jsp 增加用户界面 user_update.jsp 修改用户信息界面 user_query.jsp 用户查询界面 user_single.jsp 单个用户信息显示界
对关系密 切的元素 进行打 包，帮助 理解系统 模型
1.1.1 概述
类图：描述一组类、接口、协作及其关系； 定义静态的对象结构与逻辑设计视图； 是面向对象的软件构架的核心。 对象结构模型的粒度分割： ① 初始级类图：类构架定义（类名＋关系＋分组机制） ② 细化级类图：对象图定义（类名＋属性＋操作） ③ 精化级类图：类构架优化（结构、行为优化；构件分组）
Product
多对多的化解
供应商 1..* 0..* 客户
供应商
1
1
客户
0..* 订单
1..*
1.1.5 类图建模过程
① 设计准备 ② 标识类与对象 ③ 定义关系 ④ 定义键 ⑤ 定义属性 ⑥ 定义操作
设计准备
① 确定建模目标 ② 确定建模依据 用例图∕活动图 ③ 准备相关资料 初始类图
标识对象
表示法
visibility attribute-name : type = initial-value {property-string}
[可见性] 属性名称：类型=默认值{约束特性}
类名 属性1 属性2 … 属性n 操作1 操作2 … 操作n
属性的识别
按常识这个对象应该有哪些属性？ 在当前的问题域中，对象应该有哪些属性？ 根据系统责任，这个对象应具有哪些属性？ 建立这个对象是为了保存和管理哪些信息？ 对象为了完成其功能，需要增设哪些属性？ 对象是否需要通过专设的属性区别其状态？ 用什么属性表示聚集和关联？ 可利用需求文档中的形容词或所有格短语。
类图实例-对象级
初始类图
6.2 细化类图
细化类模型与类框架的主框架是一致的。 它对对象属性和对象操作作了详细的描述。 标识属性的过程包括确定主属性和外来属性以及全 部其它属性，根据规则检验属性的合理性，并修改和完 善数据模型，建立对象属性表。 标识操作的过程包括根据状态图标识基本操作，根 据交互图标识关键操作，建立对象操作表。
① 识别用例图中的对象 ② 对每个对象进行命名和编号 ③ 建立初始对象表 ④ 通过逐次迭代修改初始对象表，最终形成正式 对象表
定义关系
① 识别给定对象间可能存在的联系及其类型 ② 对每个联系进行命名 ③ 用继承机制定义分类结构 用聚集机制定义组装结构 标识实例连接
定义键
① 定义主键和次键 ② 键的迁移（从父对象到子对象，多属性主键必须一 次迁移） ③ 确认键和联系，主要检查规则有：
对象属性表
对象属性表主要来自于现实中的信息载体，有些 由抽象构造得到。对象属性表最终映射成数据库中数据 表格或视图。对于有大量数据项的信息载体，可根据数 据间的关系分成几部分，甚至建立多个基表。
对象属性表
表2.1账户信息类属性表 中文名 账号 密码 等级 英文名 userID password grade 数据类型 String String Menu
泛化的表示法
一般类
交通工具 驾驶 交通工具 drive() drive()
Person
drive()是 抽操作
汽车 汽车
轮船 轮船 drive() drive()
特殊类
特殊类
drive() drive()
drive()启动 轮子转动
drive()启动 螺旋浆
泛化的识别
（1）学习当前领域的分类学知识 （2）按常识考虑事物的分类 （3）利用泛化的定义 ？ 公司人员 姓名 身份证号 … 职工 姓名 工资 … 股东 姓名 股份 … 职工 姓名 工资 …
识别对象与类
从用例中识别 （1）用例描述中出现哪些实体？需要哪些实体的合 作？ （2）用例执行过程中会产生并存储哪些信息？ （3）用例要求与之相关的每个角色的输入是什么？ （4）用例反馈与之关联的每个角色的输出是什么？ （5）用例需要操作哪些设备？
审查与筛选1
舍弃无用的对象
通过属性判断：是否通过属性记录了某些有用的信息？ 通过服务判断：是否通过服务提供了某些有用的功能？ 二者都不是——无用 在应用中,一个对象应该为一些其他的对象提供服务。
定义操作
① 标识基本操作 检索：分类，选择，查询； 更新：插入，删除，修改；计算，汇总 ② 标识关键操作：消息连接 寻找一个实例所需的另一实例的操作 在已存在实例连接的对象或分类结构之间增加消 息连接
定义操作
操作建模策略： ① 识别参数、返回值及操作的可见对象 ② 若操作不太复杂，可直接用源代码表示其实现 ③ 若操作很复杂，可将其实现表示为协作； 并分别用类图和交互图展开协作的结构和行为 ④ 若操作是方法密集型的，则用活动图对它的实现 进行建模
操作的识别
有哪些类会与该类交互？ 所有与该类具有交互行为的类会发送哪些消息给该 类？该类又会发送哪些消息给这些类？ 该类如何响应别的类发送来的消息？在发送消息之 前，该类需要做何处理？ 从该类本身来说，它应该具有哪些操作来维持其信 息的更新、一致性和完整性？ 系统是否需要该类有另外一些职责？
审查
1.1.3 操作
操作是描述对象动态特征（行为）的一个操作序列。 对数据的具体处理方法的描述放在操作部分，它是类 的一个组成部分，只能作用于该类的对象上。 有名字和参数表; 有可见性和返回类型；
操作分类
基本操作 检索：分类、选择、查询； 更新：插入、删除、修改、计算、汇总 关键操作 必须由对象提供的、在算法上复杂的业务操作 （如要进行某些计算或监控操作）。
Corporate Customer Personal Customer creditCard contactName creditRating creditLimit remind() () billForMonth() ()
0..1 0..1
+LineItem
* *
1 1
Employee
OrderLine Quantity:Integer isSatisfied
StudentInfor 学生档案信息是系统需要管理的对 mation 象 Course 课程信息是系统需要管理的对象 SelectCourse 选课信息是系统需要管理的对象 Score 成绩信息无需另外用对象管理，成 绩作为选课记录的一个属性即可
1.1.2 属性
属性是类的一个已命名的性质，它描述该性质的一 个实例可以取的值的范围。 抽象为属性的性质是与问题高度相关的。 从技术观点上，属性是一些变量，包含它的每一个 对象实例都具有自己的值。 按照OO方法的封装原则，一个对象的属性和操作是紧 密结合的，对象的属性只能由这个对象的操作存取。
6.3 精化类图
在初始类图的基础上，运用三层体系结构思想对基 本类模型进行划分。根据各个对象的具体情况，将对 象分成界面、事务和数据层。
设计要点
① 类分组：单个用例／活动图的对象集／子集 ② 类分割：一个基本对象一分为二／一分为三 要与实现策略一致 ③ 事务类间的关联：三层类图中对象间的关联 按事务型对象进行组织 ④ 按活动流顺序和逻辑对象类型标识每个对象—— 对象编号
聚集的识别
（5）抽象事物的整体与部分 例：学科与分支学科、法律与法律条款 （6）具体事物和它的某个抽象方面 例：人员与身份、履历 （7）在材料上的组成关系 例：面包由面粉、糖和酵母组成，汽车是由钢 、塑料和玻璃组成。