信息系统分析与设计 第十章 系统总体设计

10.1 软件架构的设计

10.1.1 什么是软件架构

1、架构的概念
建筑、文学、音乐、机械、电子、计算机软硬件等领域都会使用“架构（architecture）”这一概念。架构都提供了系统最高层的设计方案，以确保建筑、小说、乐曲、设备、计算机等系统满足期望的特性。
-好的建筑应该美观、坚固、实用
-好的计算机应用系统应该实用、好维护、可靠、性价比高
架构师（architect）需要发现特定系统的最重要的关注点，设计某种折衷的总体方案以满足关注点。
架构包含系统的一组基本结构（structure），每种结构都有各种类型的部件（component）及其关系构成，架构描述了这些部件的组合、相互调用参照、通信以及其他动态交互。

架构和结构的关系
架构是抽象无形的，体现高层全局的决策，就像文章的中心思想和提纲。
结构是具体有形的，体现决策的贯彻，如同文章的每个段落及细节描述。

架构包含了结构的初步描述和决策。
相同架构的系统，具体结构允许有差异。
使用桥梁来比喻：
桥梁的架构设计可以使用草图描述，架构决定了桥梁的基本结构部件。
-桥梁有梁式桥、拱桥、斜拉桥、悬索桥等架构
斜拉桥的基本结构：索塔 主梁 斜拉索
桥梁的结构设计则需要考虑各种部件的数量、材料、重量、形态等方面，是可以施工的严谨的结构图。
-架构是抽象的，对结构进行了设计和限定，每座桥的结构是具体有形的、元素组合千变万化

2、软件架构
软件架构（software architecture）的定义没有统一的版本，一般认为：一个应用程序或计算系统的软件架构是一个或一组结构，它包含组成系统的软件元素、这些元素对外可见的性质以及它们之间的关系。对外可见的性质指软件元素能够提供的服务、性能特征、错误处理、共享资源的用法等。
-软件的一个结构元素可能是一个子系统、构件、进程、库、数据库、计算结点、遗留系统等等。
软件架构是最高层次的系统分解，它不会囊括所有的结构和行为的定义，它只关注那些被认为是重要的元素。
-架构难以更改，一旦修改，意味着整个系统重建，而结构修改只影响局部。
软件架构（software architecture）包括逻辑设计和物理部署两方面。
逻辑设计：通过对系统的层、包、类、接口和子系统的组织方式来描述；
物理部署: 描述了进程分配和网络配置。

3、软件架构模式
大部分的架构来源于有相似关注点的系统的总结和抽象，这些相似性被描述成某种特殊模式的架构风格，也就是架构模式（architectural pattern）。
一种架构模式就是一个经验秘籍，架构师在设计不同系统时可以重复使用这些先进经验。
-中国建筑有一种攒尖模式，被广泛应用在古典园林中，如三角、四角、五角、八角等亭子，宫殿、坛庙大量应用

软件架构模式就是可重复使用的软件结构风格。

10.1.2 多层应用架构设计

1、分层的含义
基于组件的软件开发，组件根据横向位置划分为多层（N-Layer）：
下层组件负责对上层组件提供服务
上层组件可以使用下层组件定义的服务，但下层组件对上层组件一无所知。
层与层之间通常是不透明的，每一层都具有独立的职责
不同层的软件构件可以分布在多台机器上，也可以部署在同一台机器上，形成物理上的多层（N-Tier）

层次模型的理念就是将整个任务横向划分为不同级别，而不是纵向
-比如学校管理纵向划分有教学、人事、财务、后勤等任务
-横向按管理层次划分有主管校长（高层）、部门领导（中层）、普通员工（基层），或处、科、室，按对外接待层次从公司前台、到部门秘书、再到办事人员……
计算机程序的组织结构也可以有纵向划分和横向划分
-纵向：教师管理功能、学生管理功能、课程管理功能……
-横向：界面窗体、业务逻辑类、数据访问类……

自从C/S出现之后，软件就被分层了：
Client端的软件完成前台任务，Server端的软件完成后台任务（一般是DB Server）；
Client使用Server端的服务，依赖于Server端。
自从Internet出现之后，软件进一步分层：
Client端的软件（IE浏览器）完成输入输出任务，Web Server上的程序提供业务逻辑处理，后台DB Server完成数据的存取。
C/S常被称为传统的两层，B/S称为三层。
本书的分层将不包含有关系统软件（屏蔽如IE、DBMS等内容），仅讨论应用系统本身的设计，即应用架构设计。

2、三个基本层次
应用软件内部也可以进行多层的划分。
比如一个用户注册程序可以划分为两层：
-Register.aspx/Register.aspx.cs窗体：负责界面数据的输入和格式检验，结果的输出等。
-UserDal类：负责数据库访问和注册规则检查等。
-从应用层面上看，如果整个应用软件都是采用这种方式编程（如订单处理由PlaceOrder.aspx窗体负责界面交互，由Order、Product等类负责数据库访问和订单金额计算等业务逻辑处理），那么称之为两层的应用架构。
可以有两层、三层、四层等不同分层模式。
-Register.aspx/Register.aspx.cs窗体
-UserBll类：负责注册规则检查等业务逻辑。
-UserDal类：负责数据库访问。

传统的C/S应用程序
界面窗口程序中包含所有的内容，如输入输出、界面逻辑控制、业务逻辑运算等。
系统架构是两层，应用架构没有分层。

经典的三层架构

1 表现层：处理用户和信息系统之间的交互。
-可以是简单的命令行窗口，也可以功能完善的图形用户界面（胖客户端程序），如基于HTML的浏览器界面（瘦客户端程序），也可以是手机界面。
2 业务逻辑层：也称为领域层或应用层，是信息系统所有和领域相关的工作。
-如根据输入数据或已有数据进行计算，可以是类库或Web服务。依赖于数据访问层获取数据或保存数据。
3 数据访问层：一般指与数据库的交互，主要责任是数据库记录的存取。
-如组件中包含专门的数据访问类，或每个表对应一个数据访问类

3、扩展的五层架构
1 表现层：等同于三层中的表现层。
2 控制层/中介层：是表现层和领域层的中介层，也称应用控制器。
主要表示业务逻辑中的工作流，一般针对于用例的事件流控制。此外还负责会话状态、数据的合成或分解等事务。
3 领域层：业务逻辑中的领域类的集合，不包含复杂工作流。
4 数据映射层：负责将基于对象的领域层数据映射到数据库关系表中的记录。也称为数据持久层，可自行开发或采用持久化框架。
5 数据访问层：负责数据库表的增删改查等操作。持久化框架中包含该层组件。

4、MVC架构模式
模型（Model）
-代表数据，使用对象及其属性实现。
控制器（Controller）
-是模型与视图的联系纽带，客户的请求由控制器处理，它根据客户的请求调用模型的方法，完成数据更新，然后调用视图的方法将响应结果展示给客户。相应的，模型的更新与修改将通过控制器通知视图，保持视图与模型的一致性
视图（View）
-是模型的外在表现形式，视图可以直接访问模型；查询数据信息，当模型中数据发生变化时，它会通知视图刷新界面，显示更新后的数据。

MVC架构示意图

MVC模式和三层模式有共同特点（业务逻辑、数据和表示的分离），但不完全遵守分层约定。

5. 多层的物理配置
由于应用软件封装成不同层次的独立组件，这给软件部署带来了灵活性：
物理一层：所有应用软件的组件都安装配置在一台机器上。比如全部Web程序、DBMS都在Web服务器上。
物理两层：应用软件的组件配置在两台机器上，比如一部分安装在客户端，另一部分配置在应用服务器上。
物理多层：客户端、一台或多台应用服务器、数据库服务器，即多台服务器的方式，这是分布式结构的一种形式。

多层体系结构的优势
客户对数据的访问通过中间层进行了隔离，数据库的安全性提高了。
应用程序分布部署在多个物理节点上成为可能，从而增强了处理大量的用户负载或计算任务的能力，系统可靠性和响应速度得到了提高。
业务逻辑处于不同的中间服务器，当业务规则变化后，客户端程序基本不做改动，当组件接口不变时，某一层的改动不会影响其它层，这也意味着更好的重用和可维护性（如从窗口界面变更到Web界面）。
将不同层的开发任务在开发者之间适当地分配（如一些人专注页面表现，另一些人专注于业务逻辑），有效地利用开发人员的专长和开发技巧，并且能够提高并行开发能力。

10.1.3 软件框架

“不要重复发明轮子”
软件复用：
-从代码角度（开发态）看有子过程、函数、类等
-从部署角度（运行态）看有类库、Web服务等二进制可执行组件、中间件和平台
架构模式同样可以复用，当架构模式的复用形式不仅仅停留在逻辑层面（如蓝图、方案），而以物理的二进制组件的方式提供重用时，就产生了框架。

软件框架（software framework）是对整个或部分系统可重用的设计和实现。
框架可以选择对某种架构模式的基本结构和接口机制进行编程实现，不仅封装该架构模式的基本元素对外提供类库，还封装底层公用的流程控制逻辑，从而直接为应用软件提供了最初的骨架。
框架就是一个半成品软件平台，软件框架和应用软件：
八股文 => 具体文章 （按照规范填空即可，“听课容易，解题很难，且听且珍惜”）
架构模式/框架/应用程序 => 菜谱菜式/半成品/成品菜

引入软件框架之后，整个开发过程变成了“分三步走”：
决定应用架构
选择实现应用架构的现成框架
基于框架之下编写程序（简单、统一）
优点：
代码具有相同规范和结构，易于理解和维护；提高效率；更稳定更可靠。
局限：
囿于框架所限定的“框框”之内构建应用程序，比较死板，缺乏灵活性

典型框架产品
支持MVC架构模式的框架：
Java开源MVC框架Struts
微软平台的MVC4框架
PHP的Zend框架
多种框架产品的组合使用：
如SSH（Struts、Spring、Hibernate）

Struts2简介
MVC：
View：由JSP页面实现
Model：由自行编写的Action对象完成，Action类就是一个普通的Java类，里面封装了领域对象的属性和方法，可以用于存取数据和执行有关业务逻辑。属性和方法也可以分开到不同类中。
Controller：由Struts2的内置过滤器（dispatcher filter）、拦截器（interceptor）或自行编写的拦截器来实现，过滤器和拦截器可以截获JSP页面请求，解析http请求中的参数，赋值给Action对象中对应的属性，还可以在调用Action之前或之后进行预处理或后处理。

10.2 高层结构设计

高层结构讨论系统比较大的组成部件（如包、构件、子系统等）及其接口设计。

10.2.1 包

包（Package）是一种逻辑分组手段，可以取UML模型中的任何一种事物，将相关成分聚在一起，以构成更高层的组织单元——包。
最常用的方法是将类以包为单位进行分组，比如上一节提到的层，每一层中的所有类组成一个包。
一个包可以包含其它的包，高层包被分成若干子包，子包又可以在分成更小的包。
-但在Java中，包还指代了物理的组织手段

分包（软件类的分组）有两种原则：
-共同封闭原则（Common Closure Principle）。一个包中的各个类应该是由于相似的原则而改变，即将一组职责相似、但以不同方式实现的类归为一个包中。比如按照层来进行分包就是这种类型。
-共同复用原则（Common Reuse Principle）。一个包中的各个类应该一起被复用，复用其中一个可能需要同时考虑同一个包中的其它协作类。通常和业务功能相关。

包图用来描述包及其依赖