软件系统设计方案——抽奖系统

1.项目概述

普通用户通过抽奖系统可以查询抽奖活动，进行抽奖，查看中将结果；

抽奖发布者可以管理自己发布的抽奖活动，对中将用户进行发奖；

　管理员可以通过抽奖系统管理现有的抽奖活动及用户信息；

2.项目设计方案

　　2.1 架构模式

（1）采用MVC架构模式，通常用于开发具有人机交互界面的软件，这类软件的最大特点就是用户界面容易随着需求变更而发生改变，例如，当你要扩展一个应用程序的功能时，通常需要修改菜单和添加页面来反映这种变化。如果用户界面和核心功能逻辑紧密耦合在一起，要扩展功能通常是非常困难的，因为任何改动很容易在其他功能上产生错误。将模型（Model）、视图（View）和控制器（Controller）相分离。

　　在MVC架构下，模型用来封装核心数据和功能，它独立于特定的输出表示和输入行为，是执行某些任务的代码，至于这些任务以什么形式显示给用户，并不是模型所关注的问题。模型只有纯粹的功能性接口，也就是一系列的公开方法，这些方法有的是取值方法，让系统其它部分可以得到模型的内部状态，有的则是写入更新数据的方法，允许系统的其它部分修改模型的内部状态。

　　在MVC架构下，视图用来向用户显示信息，它获得来自模型的数据，决定模型以什么样的方式展示给用户。同一个模型可以对应于多个视图，这样对于视图而言，模型就是可重用的代码。一般来说，模型内部必须保留所有对应视图的相关信息，以便在模型的状态发生改变时，可以通知所有的视图进行更新。

　　在MVC架构下，控制器是和视图联合使用的，它捕捉鼠标移动、鼠标点击和键盘输入等事件，将其转化成服务请求，然后再传给模型或者视图。软件的用户是通过控制器来与系统交互的，他通过控制器来操纵模型，从而向模型传递数据，改变模型的状态，并最后导致视图的更新。

　　2.2 架构风格

　　抽奖系统将用的是客户-服务模式的架构风格。客户代码通过请求和应答的方式访问或者调用服务代码，这里的请求和应答可以是函数调用和返回值。

　　在客户-服务模式中，客户是主动的，服务是被动的。客户知道它向哪个服务发出请求，而服务却不知道它正在为哪个客户提供服务，甚至不知道正在为多少客户提供服务。

　　客户-服务模式的架构风格具有典型的模块化特征，降低了系统中客户和服务构件之间耦合度，提高了服务构件的可重用性。

3.软件系统概念原型的不同视图

　　软件架构模型是通过一组关键视图来描述的，同一个软件架构，由于选取的视角（Perspective）和抽象层次不同可以得到不同的视图，这样一组关键视图搭配起来可以完整地描述一个逻辑自洽的软件架构模型。

　3.1 分解视图

分解视图用软件模块勾划出系统结构，往往会通过不同抽象层级的软件模块形成层次化的结构。

　3.2依赖视图

依赖视图展现了软件模块之间的依赖关系。比如一个软件模块A调用了另一个软件模块B，那么我们说软件模块A直接依赖软件模块B。如果一个软件模块依赖另一个软件模块产生的数据，那么这两个软件模块也具有一定的依赖关系。

3.3泛化视图

　　泛化视图展现了软件模块之间的一般化或具体化的关系，典型的例子就是面向对象分析和设计方法中类之间的继承关系。值得注意的是，采用对象组合替代继承关系，并不会改变类之间的泛化特征。因此泛化是指软件模块之间的一般化或具体化的关系，不能局限于继承概念的应用。

3.4执行视图

执行视图展示了系统运行时的时序结构特点，比如流程图、时序图等。执行视图中的每一个执行实体，一般称为组件（Component），都是不同于其他组件的执行实体。如果有相同或相似的执行实体那么就把它们合并成一个。

执行实体可以最终分解到软件的基本元素和软件的基本结构，因而与软件代码具有比较直接的映射关系。在设计与实现过程中，我们一般将执行视图转换为伪代码之后，再进一步转换为实现代码

3.5实现视图

实现视图是描述软件架构与源文件之间的映射关系。比如软件架构的静态结构以包图或设计类图的方式来描述，但是这些包和类都是在哪些目录的哪些源文件中具体实现的呢？一般我们通过目录和源文件的命名来对应软件架构中的包、类等静态结构单元，这样典型的实现视图就可以由软件项目的源文件目录树来呈现。

3.6部署视图

部署视图是将执行实体和计算机资源建立映射关系。这里的执行实体的粒度要与所部署的计算机资源相匹配，比如以进程作为执行实体那么对应的计算机资源就是主机，这时应该描述进程对应主机所组成的网络拓扑结构，这样可以清晰地呈现进程间的网络通信和部署环境的网络结构特点。当然也可以用细粒度的执行实体对应处理器、存储器等。

部署视图有助于设计人员分析一个设计的质量属性，比如软件处理网络高并发的能力、软件对处理器的计算需求等。