案例分析

2020年11月

第一题

（1）采用数据与行为分离的方式，数据集中存储，并和处理行为分离，处理流程独立，共享数据存储中心，交互性强 （2）数据与处理强耦合，当数据结构发生或者处理流程发生变化时，需要重启整个工作流。 （3）数据与行为分离后，数据处理性能较差，需要先读取数据再进行处理，写入操作性能较差，同时存在数据不一致性，需要交由处理侧解决冲突问题。 （4）数据与行为分离后，可支持高并发的数据读取操作和高并发流程处理操作，性能高。

第二题

问题1: 数据库的设计过程：

1. 需求分析：先进行需求分析，收集系统的需求，理解业务流程和数据需求，明确数据存储和处理目标，输出需求规格说明书。
2. 概念设计根据需求分析阶段的产物需求规格说明书进行概念设计，抽象出数据实体、属性及实体之间的关系，设计出E-R模型。
3. 逻辑设计：将E-R模型转换为关系模式，将实体转换为关系表，定义主健和外健，进行数据完整性约束，进行数据规范化，减少数据冗余，
4. 物理设计：根据逻辑设计的结果，选择合适的数据库管理系统，进行物理设计，包括数据存储结构、索引设计、分区设计等。
5. 数据库实施：根据物理设计的结果，进行数据库的实施，包括数据库的创建、数据的加载、数据库的维护等。
6. 数据库运行和维护：根据数据库的运行情况，进行数据库的维护，包括数据库的备份、恢复、优化等。

问题2: 超类实体指具有多个实体的共同属性的实体，构建超类实体有利于减少数据冗余，子类实体自动继承超类实体的公共属性，并在此基础上定义自身的特有属性。

问题3: 派生属性：派生属性作为非主属性，可以由该实体的其他非主属性所决定。

第三题

问题1:

如何把软件需求映射到软件架构：从描述语言、非功能性需求描述、需求和架构的一致性

答：软件需求到架构的映射存在的难点氛围一下三个方面

从描述性语言来说，在进行需求描述时，通常采用的是自然语言，而自然语言具有模糊性，难以表述为正确的需求，然后架构描述性语言采用的是形式化语言，具有一定的标准性，两者语言之间存在差异，映射较为困难，从自然语言到形式化语言，需要具有一定的抽象能力。

从非功能性需求描述来说，非功能性需求包括性能需求、可用性、安全性、可靠性、可修改行、可拓展性、可维护性等，这些质量属性通常很难在架构中得到完整体现，非功能性需求通常很难在架构模型中形成规约。

从需求和架构的一致性来说，软件需求映射到软件架构过程中，很难保持一致性，架构设计通常是为满足需求而设计，然后需求会随着业务的变化而不断变化，而架构设计是相对稳定的，因此很难保持一致性。

问题2:

由图可知，FACE架构架构分为5个段，分别是可移植组件段、平台服务段、I/O服务段、传输服务段、操作系统服务段。

操作系统服务段：该段为FACE架构的其他段提供操作系统基本的功能和服务，该服务段采用OSGI架构，提供运行时环境系统，为了IO服务段提供管理服务接口，包括文件管理、内存管理、处理器管理、进程和线程管理，提供软件与硬件之间的接口，为应用程序运行提供环境。

I/O服务段：I/O包括输入/输出服务，用于管理系统和外部设备之间的数据传输，这个段涵盖了与外部设备交互的功能，文件读写、网络通信IO等，同时对驱动程序进行管理，提供设备驱动接口，为应用程序提供设备访问接口。

平台服务段：平台服务段包括平台公共服务、平台图形图像服务、平台设备服务，该段主要是将公共服务进行封装，减少模块之间的耦合，同时为其他段提供公共服务。

传输服务段：该段为调用平台服务段的接口为可移植段提供数据传输和通信的能力。

可移植组件段：该段包括公共服务和可移植组件，将各平台的公共组件和服务进行封装，通过传输服务层进行通信和数据传输，以解决不同平台之间复用公共模块和实现相似功能。

问题3:

紧耦合问题主要表现在：应用业务逻辑与底层操作系统、硬件驱动或者中间件直接绑定，导致不同平台之间难以移植

解决方案：采用分离原则，通过隔离实现硬件特定信息和少数模块的代码，减少耦合

封装问题：应用内部缺乏标准接口和模块边界，功能模块间依赖复杂，无法独立替换重用。

解决方案：接口标准化，组件化，服务化