9.4 建立对象模型
面向对象分析的首要任务就是建立对象模型，建立对象模型的基本过程如下。
（1）确定分析模型中的类和对象。确定类、对象就是找出与系统相关的事物，这些事物可能是物理实体，也可能是抽象概念。通常是物理实体、人或组织、事件、事物间的相互作用和一些概念。
（2）确定对象间的关系。确定对象间的相互依赖、相互作用关系，不必过多的区分对象间到底是哪一种关系，确定这些关系来源于问题陈述中一些描述性的动词和动词词组，同时还应该找出陈述中隐含的一些关系，还有一些根据问题域得出的关联。初次确定对象间关系集合后，要进一步进行筛选，去掉不必要或不正确的关系。
（3）确定对象的属性。属性表示对象的性质。
（4）确定继承关系。利用继承机制共享共用属性和服务，对系统的对象加以组织。在系统分析阶段，对象建模的主要任务是建立问题域的概念模型。这个模型描述了现实世界中的“类与对象”以及它们之间的关系。
在UML中，通过建立类图来表示对象模型。
①划分主题；
②确定类与对象；
③确定关联；
④确定属性。
确定服务划分主题在开发大型、复杂系统的过程中，为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题。
应该按问题领域而不是用功能分解方法来确定主题。此外，应该按照使不同主题内的对象相互间依赖和交互最少的原则来确定主题。主题可以采用UML中的包来展现。
确定类与对象的步骤如下。
（1）找出候选的类与对象。类与对象是对问题域中有意义的事物的抽象，它们既可能是可见的物理实体，也可能是抽象的概念。可以将客观事物分为以下五类：
①可感知的物理实体，如教学楼、教室等；
②人或组织的角色，如教师、计算机系等；
③应该记忆的事件，如演出、交通事故等；
④两个或多个对象的相互作用，通常带有交易或接触的性质，如购买、教学等；
⑤需要说明的概念，如保险法、政策等。
另一种更简单的非正式分析方法，是以自然语言书写的需求陈述为依据，把陈述中的名词作为类与对象的候选者，用形容词作为确定属性的线索，把动词作为服务（操作）的候选者。
例如，在选课系统中，可以初步确定Teacher（教师），Student（学生），Course（课程），CourseTask（课程任务，指一门课程划分为多个任务），StudentList（学生名册），ScoreReport（成绩单）等类与对象。
（2）筛选出正确的类与对象。严格考察每个候选对象，从中去掉不正确的或不必要的类与对象，仅保留确实应该记录其信息或需要其提供服务的那些类与对象。
（3）区分实体类、边界类和控制类。在类分析时首先从问题域的实体类入手，如果在建立分析对象模型时区分实体类、边界类和控制类，将有助于理解系统。
实体类表示系统将跟踪的持久信息；边界类表示参与者与系统之间的交互；控制类负责用例的实现。其图形表示如图9.1所示。
图9.1 实体类图形表示
确定关联标识关联的启发式准则如下：
①检查指示状态的动词或动词短语，识别动作的主体和客体，从角色寻找关联；
②准确地命名关联和角色；
③尽量使用常用的修饰词标识出名字空间和关键属性；
④应消除导出其他关联的关联；
⑤在一组关联被稳定之前先不必考虑实例之间的多重性；
⑥过多的关联使得一个模型不可读。
确定属性应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。
在分析过程中应该首先找出最重要的属性，以后再逐渐把其余属性增添进去。
在分析阶段不要考虑那些纯粹用于实现的属性，具体表现如下。
①每个对象至少包含一个属性，例如_id。
②属性取值必须适合对象类的所有实例。例如，属性“会飞”并不属于所有的鸟，有的鸟不会飞，因此可以建立鸟的泛化结构，把不同的鸟划分到“会飞的鸟”和“不会飞的鸟”两个子类中。
③出现在泛化关系中的对象所继承的属性必须与泛化关系一致。
④系统的所有存储数据必须定义为属性。
⑤对象的导出属性应当略去，例如，“年龄”是由属性“出生日期”导出，它不能作为基本属性存在。
⑥在分析阶段，如果某属性描述了对象的外部不可见状态，应将该属性从分析模型中删去。
例9.1 在医院的病房里，将病症监视器安置在每个病床，对病人进行监护。监视器将病人的病症信号（组合）实时地传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。系统根据医生的要求随时打印病人的病情报告，系统还定期自动更新病历。
下面进行简单的需求分析说明，根据分析系统主要实现以下功能：
①病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统；
②中央监护系统将病人的病症信号与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警；
③当病症信号异常时，系统自动更新病历并打印病情报告；
④值班护士可以查看病情报告并进行打印；
⑤医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历；
⑥系统定期自动更新病历。
（3）用UML的静态建模机制定义并描述本系统的静态结构。
1）建立系统的用例图(https://www.daowen.com)
通过以下六个问题识别角色。
①谁使用系统的主要功能？
②谁需要系统的支持以完成日常工作任务？
③谁负责维护，管理并保持系统正常运行？
④系统需要应付（或处理）哪些硬设备？
⑤系统需要和哪些外部系统交互？
⑥谁（或什么）对系统运行产生的结果（值）感兴趣？
通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色，依次是值班护士、医生、病人、标准病症信号库。
角色描述模板：通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色分别是值班护士、医生、病人、标准病症信号库。
下面是角色描述模板，如图9.2所示。
图9.2 角色描述模板
通过分析可以初步识别出系统的用例为中央监护、病症监护、提供标准病症信号、病历管理、病情报告管理。顶层用例如图9.3所示。
图9.3 顶层用例图
2）将用例细化，可以得到分解的用例。
①中央监护。中央监护可分解为
分解信号：将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。
比较信号：将病人的病症信号与标准信号比较。
报警：如果病症信号发生异常（即高于峰值），发出报警信号。
数据格式化：将处理后的数据格式化以便写入病历库。
②病症监护。病症监护可分解为
信号采集：采集病人的病症信号。
模数转化：将采集来的模拟信号转化为数字信号。
信号数据组合：将采集到的脉搏，血压等信号数据组合为一组信号数据。
采样频率改变：根据病人的情况改变监视器采样频率。
③提供标准病症信号。
④病历管理。病历管理可分解为
生成病历；
查看病历；
更新病历；
打印病历。
⑤病情报告。病情报告可分解为
显示病情报告：在显示器上显示病情。
打印病情报告：在打印机打印病情报告。
细化的用例图如图9.4所示。
图9.4 细化用例图
3）识别系统的类
通过名词识别法和系统实体识别法等方法可以识别出系统的十二个类，以下用类图这种简单明了的方法分别表示出类的名称，属性，操作，如图9.5所示。
图9.5 系统类图
进一步地，在类图中标明类之间的关系，如图9.6所示。
图9.6 类关系图
4）用包图和配置图描述系统的体系结构
通过一定的分组机制得到以下包图，如图9.7所示。
图9.7 包图
接下来用配置图进一步描述系统的网络结构，如图9.8所示。
图9.8 网络结构图
