软件体系结构（软件架构）：{构建，连接件，约束}。
构件：组成系统的具有一定独立功能的不同粒度的程序模块等。
连接件：将不同的构件连接起来，表示构件间的相互作用，如信号量的传递、功能和方法的调用。
约束：对象连接时的规则。
软件设计过程：
概要设计：
完成软件的总体结构设计。
对每个功能模块进行功能描述、全局数据定义和外部文件定义。
做到低耦合，高内聚，降低模块接口的复杂性。
可采用层次结构图表示软件总体结构，体现自顶向下、逐步求精的设计思想。
应提供概要设计说明书等
详细设计：
细化概要设计产生的功能模块，形成可编程的程序模块。
用某种过程设计语言设计程序模块的内部细节。
还要制定模块测试方案。
可采用结构化设计方法（面向数据流的设计方法）、面向对象设计方法或面向数据设计方法。
总体设计：
对软件需求进行分解，划分成若干个子系统，定义各个子系统应事先的功能和相互间的交互关系和通信机制。
将每个子系统进一步划分为功能模块，定义各功能模块的数据结构、相互间交互关系。
二、DBAS总体设计
内容：DBAS体系结构设计、DBAS软件总体设计、软硬件选型与配置设计、业务规则初步设计。
体系结构设计：
将系统从功能、层次/结构、地理分布等角度进行分解，划分为多个子系统，定义各子系统应事先的功能。
设计系统的全局控制，明确各子系统间的交互和接口关系。
客户/服务器体系结构：（两层C/S结构）
数据管理功能在客户端上，数据处理功能在数据库服务器上。
数据库服务器可以为多个客户端应用一共共享的数据管理功能。
客户端应用可以通过网络访问多个不同数据源。
客户端除了完成人机交互功能外，还需要完成面向应用的数据处理功能，属于“胖客户端”。
浏览器/服务器结构：（三层B/S结构）表示层位于客户端，有Web浏览器实现。
客户端：根据现实逻辑完成具体的数据表示和人机交互功能，属于“瘦客户端”。
功能层：位于Web应用服务器，实现面向具体应用领域的业务规则，接收用户请求，向数据库服务器提出数据操作请求，接收数据访问结果，通过客户端将结果返回给用户。
数据层：位于数据库服务器，通过DBMS完成具体的数据存储和数据存取等数据管理功能。接收来自应用服务器提出的数据操作请求，将数据访问结果返回给应用服务器。
二者特点：使用Internet、维护工作量方便B/S优于C/S，在运行速度、数据安全、人机交互方面，B/S不如C/S。
DBAS软件总体设计：将DBAS软件系统分解为一系列子系统，为各子系统分配相应功能，定义子系统间的协调相互机制。
软硬件选型和配置设计
业务规则初步设计：用业务流程图表示出来。
三、DBAS功能概要设计
表示层：负责所有与用户交互的功能。
业务逻辑层：根据业务逻辑将表示层获取的数据进行组织后传递给数据访问层。
数据访问层：与DBMS系统进行交互，提取或存入应用系统所需的数据。
数据持久层：数据组织和存储。
表示层概要设计：主要任务是人能及界面设计。
业务逻辑层概要设计：高内聚，低耦合。构件间接口明确。如果构件过于复杂，可进一步细分。
数据访问层概要设计：主要任务是针对DBAS的数据处理需求设计用于操作数据库的各类事务。
事务的特性：原子性、一致性（保证事务的操作状态是正确的）、隔离性（互不打扰）、持续性（影响是永久的，对于撤销的事务影响可以消除）。
四、DBAS功能详细设计：
表示层详细设计：初步设计、用户界面细节设计、原型设计与改进。
业务逻辑层详细设计：
根据概要设计中定义的个程序模块功能和输入输出数据需求，设计各模块的内部处理流程和算法、数据结构、对外接口，是对概要设计的细化。
可以通过UML类图、活动图、协作图来描述DBAS对用户业务的详细实现逻辑。
五、应用系统安全架构设计
数据安全设计：
安全性保护、完整性保护、并发控制、数据库的备份与恢复、数据加密传输。
安全性保护：
用户身份鉴别：windows集成，用户名和密码。权限控制、视图机制：建立用户时设好权限等级。
视图机制：即使数据存在，但用户看不到它们。
完整性保护：指正确性、一致性、相容性。
防止假如不合语义的数据。
方法：设置完整性检查，即对数据库中的数据设置一些约束条件。
作用对象：分为列、元组、关系三种级别，列：值的类型、范围、精度、排序，元组：各个属性间的约束（主键约束，外键约束）。
完整性约束条件的设置由用户通过完整性约束语句给出，完整性检查由数据库管理系统完成。
排它锁x和共享锁s。
避免死锁：同一顺序访问资源。
采用小事务模式，尽量缩短事务长度。
使用记录级别的锁（行锁），少用表级别的锁。
使用绑定连接。
解决方法：基于封锁方法、基于撤回方法
事务：
一条或多条SQL语句的一次执行。
可串行性：一个调度对数据库的状态的影响都和某个串行调度相同
冲突：
什么是锁：
排它锁X：只有一个一个事务能读，写，其他事务不能读、写。
共享锁S：所有事务都可以读，但任何事务不能写。
更新锁U
增量所I
相容性（矩阵）：
有S锁，其他能申请S，不能申请X
有X锁，其他不能申请S和X
饿死：数据项A现在有共享型锁，T1对数据项A申请排它锁，此时需要等待A上锁的释放，但是此时T2向A申请了共享型锁，因为是相容的，所以当A上刚开始的共享型锁释放后，T1还需等待T2，而此时，T3又向A申请了共享型锁……那么T1的加锁申请一直不能的得到满足，称饿死。
如何避免饿死？
假如T对Q申请的M型锁
1.不存在对Q持有与M不相容的锁
2.不存在等待Q加锁且先于T申请加锁的事务
这样，一个加锁申请就不会被其后申请加锁的事务所阻塞。
封锁协议（加/解锁时机）：
隔离性级别：
两段封锁协议：对于每一个事务，在有加锁的地方前不能解锁，在有解锁的地方前加锁。